Path: 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

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