Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!lll-winken!sun-barr!newstop!sun!angel!henry From: henry%angel@Sun.COM (Henry McGilton -- Software Products) Newsgroups: comp.lang.postscript Subject: Re: EPS Summary: EPS Is A State Of Mind, not A Set Of Comments. Keywords: EPS Message-ID: <129496@sun.Eng.Sun.COM> Date: 20 Dec 89 22:56:31 GMT References: <1989Dec18.131827.11383@swssai.uucp> <604@cherry5.UUCP> Sender: news@sun.Eng.Sun.COM Lines: 130 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. | | +-------------------+---------------------------+---------------------------+