Article View: comp.lang.postscript
Article #8627Re: EPS
From: C.E. Thompson
Date: Thu, 21 Dec 1989 13:22
Date: Thu, 21 Dec 1989 13:22
102 lines
4902 bytes
4902 bytes
In article <129496@sun.Eng.Sun.COM>, henry%angel@Sun.COM (Henry McGilton
-- Software Products) describes in general terms the (semantic, not
syntactic) constrains on an EPS file, and also describes a number of
specific restrictions.
Unfortunately, some of these need clarification, because he doesn't
distinguish carefully enough between what the included PostScript must
do and what must be done by the includer.
> o most important is that the well behaved
> Encapsulated PostScript program not make
> unwarranted assumptions about where it is going.
> Assuming that the PostScript is going straight to a
> printer is the worst unwarranted assumption.
No argument there.
> o the Encapsulated PostScript program encloses itself
> nicely in a save / restore bracket, and cleans up
> after itself.
No, it is the job of the including process to add a save/restore
round the inclusion.
> o the Encapsulated PostScript certainly should not
> change the state of the server.
Quite so. Ideally, a document that *does* change the state of the server
begins "%!PS-Adobe-2.0 ExitServer".
> o the Encapsulated PostScript program defines and uses its
> own dictionaries, instead of placing definitions in the
> dictionaries of the including program.
Well, that is not strictly a requirement of EPSF, although it is
"recommended". The main reason for doing is not that it will upset
the including program (the dictionary contents will revert on the
'restore') but that one shouldn't assume there is enough space left
for your definitions, either in the current directory or in 'userdict'.
> o the Encapsulated PostScript program leaves the
> operand stacks in the state they were in when the
> program started.
True. However, many including processes don't leave anything on the
operand stack at the point of inclusion, because they don't trust
the included program in this respect, probably with good reason!
> o the Encapsulated PostScript program refrains from
> using printer-specific page setup procedures, and
> refrains from making assumptions about the size of the
> printable area, in other words, refrains from making
> the assumption that it's going to a printer at all.
The graphics state at the point of inclusion may not be the default
state (in particular the current transform may be quite different),
but the including program *is* responsible for resetting (if necessary)
*some* parts of the graphics state; equivalent to
0 setgray 0 setlinecap 1 setlinewidth 0 setlinejoin
10 setmiterlimit [] 0 setdash
newpath
> o the Encapsulated PostScript program refrains from
> using certain operators like initgraphics,
> initmatrix, grestoreall, and initclip, all of which
> hose assumptions that the including program might
> have made.
Correct.
> o the Encapsulated PostScript program, instead of
> just doing settransfer and setscreen, thereby hosing
> those parameters for the including program, first
> obtain the current state of those parameters, and
> augment them, use them, then restore them to their
> original states at the end.
The restoring will be done for you by the including program's 'restore'.
> o the Encapsulated PostScript program does not place
> oddball control characters like control-D and
> control-Z characters anywhere within itself so as
> to hose the including program when the time comes
> to print or image. Apologies to all for exhuming
> this already flogged, dead, and moldering horse.
Indeed, no PostScript-generating program, whether it is generating
EPSF or not, should include such control characters. Unfortunately,
this is more like a dead vampire than a dead horse.
You didn't mention the dreaded 'showpage'. As a concession to the real
world, it is the job of the including program to disable 'showpage';
the EPSF file is allowed to use it (but need not).
You can find all this in the "Encapsulated PostScript Files
Specification Version 2.0", which is available from the Adobe
fileserver.
Chris Thompson
JANET: cet1@uk.ac.cam.phx
Internet: cet1%phx.cam.ac.uk@nsfnet-relay.ac.uk
Technical Details
Message-ID:
<1705@gannet.cl.cam.ac.uk>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!mcsun!ukc!cam-cl!cet1References:
<1989Dec18.131827.11383@swssai.uucp> <604@cherry5.UUCP> <129496@sun.Eng.Sun.COM>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!mcsun!ukc!cam-cl!cet1 From: cet1@cl.cam.ac.uk (C.E. Thompson) Newsgroups: comp.lang.postscript Subject: Re: EPS Keywords: EPS Message-ID: <1705@gannet.cl.cam.ac.uk> Date: 21 Dec 89 13:22:05 GMT References: <1989Dec18.131827.11383@swssai.uucp> <604@cherry5.UUCP> <129496@sun.Eng.Sun.COM> Sender: news@cl.cam.ac.uk Reply-To: cet1@cl.cam.ac.uk (C.E. Thompson) Organization: U of Cambridge Comp Lab, UK Lines: 102