Make Digital File Exchange Easier
This column is the second in a series of "Digital Directions" columns, through which I'd like to discuss how we can make the process of ex-changing digital files easier. Last month, we took a look at TIFF/ IT-P1; this month, let's take a closer look at PDF/X.
PDF/X-1: The evolution
PDF/X was lauded as the accredited file format for the masses. Its goal was to enable those who wanted to create ad materials themselves but could not afford expensive, proprietary equipment. The format promised us all a way of making secure, reliable files—or at least more secure and reliable than the native application alternative.
A great number—sadly, perhaps even the majority—of ads are still exchanged as native documents. It never ceases to amaze me when I hear stories of CTP disasters traced back to native application files. These tales make Steven King's stuff read like fairy tales! Cujo's family merely had to worry about a rabid dog bite. A group of New England kids feared "IT" for most of their lives. But these horrors are nothing compared to a makegood!
Fearing those pesky native apps, many publishers and printers have turned to PostScript files instead, hoping that it would solve some of the typical mishaps—font substitutions, text reflow and the like. But it didn't. The file format is fraught with its own set of issues. Then, along came PDF, our next proposed digital ad savior. For only a few hundred dollars, publishers and ad agencies could buy the tools to translate original documents into a format that is: device independent, has embedded fonts and graphics, is uneditable (unless you had specific tools to make revisions), could be viewed by just about anyone, and was small in size.
The problem with PDF files, however, is that the format was designed to support both print and non-print (Web publishing) output. This meant that when distilling the file, creators had a plethora of setting choices. PDF, for example, tolerates RGB, unsuitable for print. Embedded fonts may be forgotten. Resolution can be low, and crop and bleed marks are easily overlooked.
Then came PDF/X, established to address these fundamental mishaps. It promised to make PDF creation fool-proof. We thought it was going to encourage the masses, who were guity of sending out naked documents, to dress them in more protective attire.
Many developers (CSG Publishing, Harlequin, Rorke Data, CreoScitex and Shira, just to name a few) rushed to make products that write PDF/X-1-compliant files. Notice anything in particular about this list? Each developer offers RIPs that rasterize file data, which means that their products are rasterizing the PDF/X-1. In a nutshell, the technologies take the CT and LW and adds a PDF/X-1 wrapper. There's nothing wrong with this solution. In fact, it's a very good one. The process can reduce file size by as much as 50 percent. What these technologies do not address, however, is the conversion to PDF/X-1 from native applications. And so print producers are back in the same old boat. If they couldn't afford to create and process TIFF/IT-P1 files, they won't be able to afford this method for PDF/X-1 either.
The question we're all anxious to have answered is: Is anyone making an inexpensive desktop solution that can write vector/raster PDF/X-1 files? Apago's Piktor is now available with a PDF/X-1 Creator Module that runs on Windows 2000/NT ($1,500), but it leaves Mac fans out in the cold. The developer does promise a Mac-version release of its PDF/X Check-up later this month. For $149, you'll get a program that checks the PDF file, automatically corrects non-compliant elements and applies PDF/X-1 tags. Now we're talking! It's still one step away from being able to generate a PDF/X-1 file directly from your native application, but it's one step closer to where we need to be.
-Linda Manes Goodwin
Linda Manes Goodwin (firstname.lastname@example.org), is a CTP evangelist. As executive director of Manes Goodwin Associates, she specializes in optimizing digital print production workflows.