Thursday, January 24, 2008

I stumbled across a statement in an forum that there was no longer any use for EPS files, as anything and everything you ever needed to do you could do with PDF.

As someone who has been banging that gong since Acrobat version 2.1 - and made a living making being a PDF Evangelist




I still wondered "-- but is that really accurate? Have I drank too much of the Kool-aid ?.

So, the back story is here - InDesign Secrets (post by Sandee "vectorbabe" Cohen)

I took the question seriously and passed it around to the usual suspects - my friend Dov Isaacs at Adobe had mercy on my ignorant soul and took the time to explain in such WONDERFUL detail and with such clarity I felt it deserved a place on some blog - perhaps some other more professional blogger will post it, as this blog is more personal - but here is what Dov explained- he wrote;

As the person at Adobe who is probably the most involved in this area, a few thoughts:


(1) One of the major differences between PostScript and PDF is that PostScript is primarily a programming language with pre-defined (and redefinable) graphic operators and PDF is a declarative page layout language. PostScript can interact with its environment and dynamically invoke graphics operators based on external conditions; PDF is static.


(2) One ramification of (1) above is that PDF is deterministic while PostScript is not. Without fully interpreting a PostScript file, you cannot make any assumptions about what if any output you will get upon any one such interpretation of the PostScript stream. PDF is constant. You will always get the same number of pages and content rendered from a given PDF file. By virtue of this issue alone, PostScript can be fairly unreliable as a container for static graphic content.


(3) A further ramification of (1) above is that typical PostScript emitters tend to take advantage of the programmability of PostScript to yield output streams that are virtually impossible for direct human interpretation by virtue of their use of layers upon layers of procedure definitions.


(4)To make matters even worse, the overhead of defining and accessing such PostScript procedures adds tremendous program interpretation overhead to the cost of rendering the underlying graphic content. This issue is discussed in detail and illustrated in John Warnock’s famous “Camelot” paper from the early 1990’s (copy attached) that formed the basis of Adobe’s Carousel project that ultimately yielded PDF and Acrobat. For typical output from a graphic arts program or even standard platform PostScript drivers, the time it takes to render PostScript versus the content in PDF is often significantly greater.


(5)With the exception of minor tweaks, the definition of PostScript was completed with PostScript Language Level 3, announced nearly 12 years ago. There are no plans by Adobe to augment the PostScript imaging model. In the meantime, PDF augmented the imaging model well beyond that of PostScript including support for (a) ICC color management, (b) objects with transparency (i.e., objects that are translucent, not 100% opaque) including 16 blend modes and other features and attributes, (c) layers (for versioning, for example), and (d) native support for embedded OpenType fonts (not just taking the Type 1 or Type 42 outlines from same for embedding).


(6) Adobe applications allow authoring using the imaging model features of (see 5) above. Furthermore, even Microsoft and Corel support transparency in their applications and provide means for output via PDF (via native or Adobe tools) of such transparency.


(7) Although you can theoretically include all imaging attributes in PDF that you can in PostScript, good practice dictates that you don’t! Most RIP products, including consumer PostScript devices already ignore many of these attributes and optimize for the device and consumables used. Some devices allow for honoring such attributes; others don’t.


(8) Per Sandee’s challenge, I support her view but even stronger. In use of InDesign as a layout program, there is really no advantage whatsoever of using EPS as the vehicle for placing pure raster images. In fact, if you have a complex Photoshop file that uses vector, text, transparency, and extra color channels, PDF is really the only viable means of placing such artwork in InDesign maintaining full fidelity of text as text, vector as vector, transparency, and additional spot color channels. EPS cannot handle all of that.


We are moving towards replacement of PostScript with native PDF in terms of RIP products, beginning at the top, i.e. CtP and proofing products followed by DFEs for high speed digital presses. Use of PostScript in any intermediate stage of such workflows only tends to degrade quality, reliability, and device independence. The newest standards for PDF/X,

PDF/X-4 and PDF/X-5 are based on the concept of maintaining content at the highest level of abstraction until rendered, supporting live transparency and color-managed objects in addition to versioning and VDP. Job control is not in the PDF, but via JDF, allowing the PDF to be as device independent as possible.


In terms of PostScript, it is not going away. Our position on PostScript at Adobe is as follows:


(1) Adobe will continue to provide PostScript-based products via our OEM partners
as long as there is a demand for same which of course is driven by the market.


(2)Adobe will continue to support creation of PDF via distillation of PostScript assets.


(3)Adobe will continue for the indefinite future to support the many billions of
existing EPS-based graphic assets via placement of same in Adobe graphic arts products. Unless a user needs to add support for transparency or color management to such existing resources, we certainly do not encourage massive asset conversion to PDF.


(4) On the other hand, for new content, Adobe most strongly recommends workflows in which all objects are ICC color-managed and support the full PDF imaging model. Creation of new graphic assets as EPS as far as we are concerned have only one valid raison d’ĂȘtre – the ability to reliably place same in QuarkXPress-based workflows.

1 comment:

Laurens said...

Nice summary!