Bindy,

Here's a bit of wisdom from a long-time friend of Adobe Software, Steve Rindsberg:

EPS (Encapsulated PostScript Files) are strange bunnies. When you import them into your DTP or presentation program, they behave differently than the other imports you're used to. Here's the Why and Wherefore.

First of all, EPS is NOT the same as PostScript (such as you'd produce by printing to disk using a PostScript driver). It can contain nearly all the same commands and graphics as a regular PS file, but some PS operators are strictly verboten in EPS. Moreover, EPS contains no page setup information and might not contain a "showpage" command ... the PS equivalent of "Print 'em, Dan-o". An EPS may print if you send it to a PS printer, but it may not. Them's the breaks.

Neither is EPS the same as AI, or Adobe Illustrator format. The old version of the .AI format was a very restricted subset of EPS intended for importing apps to translate into their own format. The NEW version of the .AI format (since AI9) is now a form of PDF, which allows transparency and other neat effects.

An EPS file contains one image only; in other words, it cannot contain multiple pages, but each image may be made up of several other images.

What happens when you import an EPS file? First of all, let's use the term "place" rather than "import" since the mechanics of EPS are different from regular imports.

There are two general classes of EPS file, those with a preview image and those without. If the EPS includes a preview image, then that's what you see when you place the file. The preview may be TIFF or WMF if you're working on a PC, PICT if you're a Mac user. Some, though not all, Mac programs support TIFF as well. That's a hint as to which you should use if you're bi-platformal. Got it?

If there's no preview image in the EPS, there's nothing for your app to show you. Instead, you get a box that's the same proportions as the EPS file (the box size is derived from the %%BoundingBox comment that MUST be in every EPS). You may also see some of the other text from the header section of the EPS ... things like BoundingBox, Creator, and whatnot. Not very WYSIWYG, but more useful than a plain grey or white box all the same.

Note that your app makes no attempt whatever to interpret or convert the actual contents of the EPS file. This is Right and Proper behaviour.

At print time, one of two things happens. If you're printing to a PostScript printer, your app simply spits the contents of the EPS back out to the printer, bounded with a few other commands to establish the scaling and position of the image. Again, it makes no attempt whatever to understand what's actually IN the EPS.

If you're printing to a non-PS printer, your app can't very well send raw PS out the port, since that would cause your printer to a) croak, or b) spew pages and pages of raw PostScript gibberish, or c) all of the above.

Instead, it sends the preview image, if there is one, or our old friend the empty box if there isn't. The quality of the printout will depend on the resolution of the preview image.

Some EPS have very low resolution, low quality previews, others may have full-color, high resolution preview images or even fully scaleable vector WMF previews. If you print an EPS to a non-PostScript printer all you'll see is the header unless the application has a built-in software RIP like Illustrator and InDesign.

And,unlike .AI files, EPS are NOT meant for editing -- only printing.

Adapted from a diatribe by Steve Rindsberg

bindy_l

Replied in the following topics

EPS files - unable to open because the parser module cannot parse???