alfred@dutesta.UUCP (Herman Adriani & Alfred Kayser) (12/05/88)
I tried to look up some information about EPS too, but i couldn't find
something about it. I do have to postscript cookbook and I have seen
the red book. But, as some other people on this net, I need some info
very fast. So if someone knows everything about EPS, please share your
knowledge with us. (and we should be happy with that).
Totally unrelated question: Is there a PD source of a postscript 'previewer'
available or at least something usefull.
Thanks in advance.
Herman Adriani.
--
_____________________________________________________________________________
/ \
| Herman Adriani & Alfred Kayser: Computer fans especially from 24 pm to 7 am |
\_____________________________________________________________________________/tom@nlgvax.UUCP (Tom van Peer) (12/06/88)
Adobe maintains a file-server from which you can get the EPS specifications. You can get these specifications by sending a message to: ps-file-server@adobe.com Your message should contain the following line: send documents EPSF.ps If you want to know more about this server try "help". If you can't get the file, you can ask me for a copy. -- Tom van Peer. E-mail: mcvax!nlgvax!tom or tom@nlgvax.pcg.philips.nl or peer@vangogh.prl.philips.nl
babcock@adobe.COM (Rob Babcock) (12/06/88)
For all those who have inquired about Encapsulated PostScript(R) Files... Adobe Systems publishes the specification for EPS as well as a number of documents. These include: Encapsulated PostScript Files Specification - V2.0 Document Structuring Conventions Specification - V3.0 Cooperative Printing: Guidelines for distributed printing - V1.0 PostScript Printer Description Files Specification - V3.0 Requests for these documents should be sent to: Adobe Systems Incorporated Att: Developer Support 1585 Charleston Road Mountain View, CA 94039 USA Also ask for an application to our Developers' Association, which is intended for serious product development teams who are interested in using the PostScript page description language in conjunction with their products or business. I hope this helps.
kamran@swssai.uucp (kamran sokhanvari) (12/18/89)
Does anyone knows of the existence of a program/filter that transform a plain Postscript file into an EPS (Encapsulated Postscript) file? I want to include some graphics (decribed in Postscript) in FrameMaker. Graphics should be imported in FrameMaker as EPS files so that they can be viewed on the screen. As I know, there is a bitmap decription part in the EPS file that is used for displaying on the screen. The problem is how to generate this bitmap from my Postscript decription? alain%swssai.uucp@uunet.uu.net (Alain Hsiung Swiss Life R&D General Guisan Quai 40 CH-8022 Zurich).
dkazdan@cwsys2..CWRU.Edu (David Kazdan) (12/20/89)
In article <1989Dec18.131827.11383@swssai.uucp> alain%swssai.uucp@uunet.uu.net (alain hsiung) writes: > > >Does anyone knows of the existence of a program/filter that transform >a plain Postscript file into an EPS (Encapsulated Postscript) file? What exactly *is* the difference? My programs that generate this sort of stuff all produce .eps files and I have wondered what "regular" PS files are. --David
murphyn@cell.mot.COM (Neal P. Murphy) (12/21/89)
In article <1989Dec19.174416.2279@usenet.ins.cwru.edu> dkazdan@cwsys2.UUCP (David Kazdan) writes: >In article <1989Dec18.131827.11383@swssai.uucp> alain%swssai.uucp@uunet.uu.net (alain hsiung) writes: >> >> >>Does anyone knows of the existence of a program/filter that transform >>a plain Postscript file into an EPS (Encapsulated Postscript) file? > > >What exactly *is* the difference? My programs that generate this sort of stuff >all produce .eps files and I have wondered what "regular" PS files are. > >--David he 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, for you fans who are still out there) %%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 thtat 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. NPN
halliday@cheddar.cc.ubc.ca (Laura Halliday) (12/21/89)
In article <604@cherry5.UUCP> murphyn@cell.mot.COM (Neal P. Murphy) writes: >eps PostScript code: >--------------------------------------------------------------------------- >%!PS-Adobe-1.0 Not quite. This should read: %!PS-Adobe-1.0 EPSF-1.2 Or whatever versions of the Document Structuring Conventions and EPSF format you're following. ...laura
henry%angel@Sun.COM (Henry McGilton -- Software Products) (12/21/89)
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. | | +-------------------+---------------------------+---------------------------+
cet1@cl.cam.ac.uk (C.E. Thompson) (12/21/89)
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