🚀 go-pugleaf

In article <604@cherry5.UUCP>, murphyn@cell.mot.COM (Neal P. Murphy) writes:

    *  The difference:

    *  regular PostScript code:
    *  -------------------------------------------------------
    *  72 360 moveto
    *  /Helvetica findfont 72 scalefont setfont
    *  (Postscript) dup stringwidth pop 468 add 2 div 0 rmoveto show
    *  showpage
    *  -------------------------------------------------------

    *  eps PostScript code:
    *  -------------------------------------------------------
    *  %!PS-Adobe-1.0
    *  %%Title: PostScript
    *  %%Creator: Neal P. Murphy
    *  %%CreationDate: 20 December 1989 (DEC-20 day)
    *  %%DocumentFonts: Helvetica
    *  %%Pages: 1
    *  %%BoundingBox: 72 350 540 450
    *  %%EndComments

    *  %%Page: 1 1
    *  %%PageFonts: Helvetica

    *  72 360 moveto
    *  /Helvetica findfont 72 scalefont setfont
    *  (PostScript) dup stringwidth pop 468 add 2 div 0 rmoveto show
    *  showpage

    *  %%Trailer
    *  -------------------------------------------------------

    *  You'll note that the executable code is identical in
    *  each case. The difference is found in the comments; the
    *  comments enable some other application to figure out
    *  the sizes and requirements of a PostScript object,
    *  allowing it to include the object in its own file and
    *  perhaps even manipulate it. An example is a print queue
    *  mangler, which will read these comments to find out
    *  what fonts need to be downloaded to the printer, to
    *  print the pages in reverse order, perhaps even to
    *  change its layout - 1-up to 2-up, for example. While
    *  both are perfectly valid PostScript code, the latter
    *  has structured comments which allow other applications
    *  to use the code within.

Yes, well.  That's OK as far as it goes, but it's not quite
the whole story.  EPS means more than just a set of
comments.  You can in fact have an EPS file that doesn't
have any of those comments.  EPS is more a state of mind.

Examine the name of the beast carefully -- ENCAPSULATED is
the key word.  The purpose of EPS files is that you can
include them into another piece of PostScript, and have
them come out the way you want them to.  Suppose you're
writing a paper on how pages ought to look.  You'd like
some illustrations of some miniature pages.  The best way
to get that is to create some regular sized pages using
your favorite document formatter, then include the pages,
scaled down.  Ned Batchelder's and Trevor Darrell's paper on
psfig is a really good example.

The important thing about an EPS file, whose possible
destiny is to be included in another PostScript file, is
that is WELL BEHAVED.  What does this mean?  Well behaved
means that the Encapsulated PostScript program doesn't
disturb the environment of the including program.  Well
behaved means, among many other things:

    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.

    o   the Encapsulated PostScript program encloses itself
        nicely in a save / restore bracket, and cleans up
	after itself.

    o   the Encapsulated PostScript certainly should not 
        change the state of the server.

    o   the Encapsulated PostScript program defines and uses its
        own dictionaries, instead of placing definitions in the
        dictionaries of the including program.

    o   the Encapsulated PostScript program leaves the
        operand stacks in the state they were in when the
        program started.

    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.

    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.

    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.

    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.

Having written this and other notes of the same ilk, I'm
thinking we need something along the lines of Henry Spencer's
Ten Commandments for C Programmers.  The Ten Precepts of PostScript.

	.................. Henry
+-------------------+---------------------------+---------------------------+
| Henry McGilton    | I'll bet those people who |                           |
| Sun Microsystems  | put control-D characters  | arpa: hmcgilton@sun.com   |
| 2550 Garcia       | in PostScript files also  | uucp: ...!sun!angel!henry |
| Mountain View, CA | put beans in their chili. |                           |
+-------------------+---------------------------+---------------------------+