This content has been marked as final.
Show 5 replies
-
1. Re: Why .eps?
Teri_P Sep 27, 2006 4:32 PM (in response to (christina_poulsen))These two essays by Mordy Golding may help:
http://rwillustrator.blogspot.com/2006/01/eps-is-dead-to-me-or-is-it.html
http://rwillustrator.blogspot.com/2006/09/props-to-all-prepress-folks-out-there.html -
2. Re: Why .eps?
JETalmage Sep 27, 2006 5:20 PM (in response to (christina_poulsen))EPS. Encapsulated PostScript.
The operative word is Encapsulated.
The purpose of EPS is to provide a "package" which can contain (encapsulate) PostScript data which a PostScript printer can understand, but which a program which may need to include the content may not understand. The importing program doesn't have to understand the content of the EPS "locked box." It can simply pass it on to the printer.
Example: Microsoft Word is not considered "a PostScript program." But it can import and place on the page an EPS file. The EPS file contains a low-res raster representation of the content of the EPS file so the Word user can have a (rough) visual idea of the content of the file while he is positioning it in his Word document. It looks lousy on-screen, but he can put it on the page and scale it, rotate it, etc. But it's otherwise a "locked box" as far as Word is concerned. Word can't "break into" the box to manipulate the vector or raster native elements it contains.
If the Word user prints the page to a non-PostScript printer, that printer won't understand the contents of the "locked box" either. It will just print the screen pixels of the low res preview.
But if the Word user prints the page to a PostScript printer (a printer with a PostScript "brain"--a PostScript interpreter), the fact that the PostScript code is encapsulated means that Word can just pass the package that it doesn't really understand on to the printer, along with the Word-native elements on the page. The PostScript printer knows how to read the encapsulated data contained in the EPS, and can render the contents in their full resolution and/or resolution-independent vector glory.
Quark XPress is considered "a PostScript program." That is, when it prints, it can translate the XPress-native objects on the page into PostScript code. But that doesn't mean it can understand object data that is native to some other PostScript program (Illustrator, for example). So again, that other program exports its artwork as an EPS "locked box" or "package". Just as before, the EPS contains a low-res raster representation of the real contents, just to give the XPress user something to see when positioning the EPS container on the page amid the various XPress-native objects.
So the Xpress user prints the page to a PostScript printer. XPress knows how to translate its objects into PostScript code that the printer can understand, but it still doesn't understand the Illustrator-native objects contained in the EPS. So XPress just passes that EPS along to the printer as a package. The printer's PostScript brain interprets the PostScript code written out by XPress and interprets the PostScript code which Illustrator wrote into the the encapsulated package.
Now all that is, as you say, somewhat old-world nowadays. The reason is because Adobe:
(1) Created PDF, which is kind of like PostSript. Think of it as PostScript that is already "halfway interpreted" so it can be printed on both PostScript and non-PostScript devices.
(2) Enabled Illustrator and other Adobe apps to export PDF as well as EPS.
(3) Enabled all the Adobe print-graphics apps to import each other's PDF files as spot-graphics. For example, you can place a PDF generated by Illustrator into InDesign. This allows more interactivity between the imported PDF content and the native objects created in the importing Adobe app. So, for example, you can save a logo created in Illustrator, or a vignetted image created in Photoshop; and place them in InDesign. InDesign can then apply a soft-edged drop shadow to the imported PDF.
Non-Adobe apps have been having to play catch-up in this ability to deal with PDF content as spot graphics (partial content of a page). I'm not sure how far XPress has come in this regard, because I haven't been upgrading my copy of XPress since InDesign was introduced. So for cross-app workflows which involve cross-vendor applications (not just XPress), older solutions like EPS are still more important. But in an all-Adobe print graphics workflow, PDF can pretty much obviate the need for EPS.
When you save an Illustrator file with the option turned on for "PDF Compatibility", that means that the Illustrator file also contains a full duplicate of the content in PDF format. When that "Illustrator" file is placed in InDesign, InDesign actually imports the PDF version, not the native Illustrator version.
When you save a PDF file from Illustrator with the option turned on for "Maintain Illustrator Editability"; again, two full versions of the content are saved. If you later re-open that "PDF" in Illustrator, Illustrator actually reads back in the native Illustrator version, not the PDF version (so, for example, a Blend is still a Blend).
If you save the PDF from Illustrator with the Maintain Illustrator Editability option turned off, Illustrator just saves the PDF version. Illustrator can still re-open the PDF and tear it apart, but the objects will be "more basic" objects. Blends, for example will be stacks of separate paths.
So the bottom line is, EPS is much less important these days for a print-graphics workflow if you are using all Adobe apps. But it can still be important if the workflow involves non-Adobe apps.
JET -
3. Re: Why .eps?
Teri_P Sep 27, 2006 6:16 PM (in response to (christina_poulsen))Very good summary, JET. I will flag this thread as a keeper.
Here is an amusing and informative, if lengthy, older thread about saving as PDF vs saving as .ai. It doesn't have much to say about EPS, though.
jeffkr, "AI vs. PDF format" #, 1 Apr 2006 2:38 pm -
4. Re: Why .eps?
John Danek Sep 28, 2006 7:39 AM (in response to (christina_poulsen))Getting back to Christina's original question, (whew! ) typically EPS's render a little worse on screen. The preview could be 72ppi, whereas PC's preview is 96ppi, which makes matters worse. Save those EPS's as .tif's in Photoshop or export them as .tif's from Illustrator and they should appear much better on screen and when they print. EPS's are still in the print workflow. So, yes, to answer your question, print shops may still need the EPS based on their RIP workflow. The vendors should not be sending you EPS's based on your TV / Video production workflow. -
5. Re: Why .eps?
Sarah@CEL Oct 27, 2009 7:07 PM (in response to JETalmage)Wow ... Bumping this back up
Sorry to drag stuff up that about 3 years old, but as a newbie I found this very helpful.
Thanks JETalmage


