Editor's Note: As Martin Bailey of Global Graphics explains in the FAQ document he periodically updates on PDF/X, the acronym stands for "a focused subset of PDF designed specifically for reliable prepress data interchange." He last updated the PDF/X FAQ in early 2002. When we heard recently there was news on the prepress standards approval front, we went straight to the source: Bailey also chairs the committee working on the PDF/X standards. He brings us up-to-date in the following article.
The PDF/X standards provide a robust subset of the Portable Document Format (PDF) specification, designed to enable reliable transmission of files from one site to another in the print industry. With the recent release of several high-profile applications that include explicit support for PDF/X, interest in the standards is reaching new heights.
The two current PDF/X standards both define a subset of the PDF file format and also appropriate handling of those files in a prepress workflow:
PDF/X-1a:2001 - CMYK and/or spot color workflows
PDF/X-3:2002 - color-managed workflows, with or without CMYK and spot color elements
You can find much more information about both the standards themselves and about applications to create and consume the files at PDF-X.com or PDFX.info.
Developing and maintaining standards like PDF/X is always a bit of a balancing act.
If the standard is based on too old a version of the PDF specification, there will be complaints from users at the creation end of a PDF/X exchange that they can't use the wizzy, new features of the latest revision.
On the other hand, if it's kept right up with the leading (or bleeding) edge of new PDF versions, there will quite rightly be complaints from prepress companies at the receiving end of a PDF/X exchange that they can't handle the files without constantly upgrading to the most recent versions of their tools ... or even that the tools they need are simply not available yet.
Most vendors will support PDF/X in products that also support 'baseline' PDF. If the standard is based on too old a version of PDF, it becomes hard for those vendors to maintain a code base that can simultaneously support the most recent versions of PDF and the one required for PDF/X.
If it isn't reasonably easy for vendors to support the standard, there won't be any tools available. Falling into the kind of pitfalls described above for people creating and receiving files the standard means it wouldn't get used anyway, especially as the details of the file format you're working with tend to affect the whole of your prepress workflow.
It can sometimes be very tricky to figure out where to draw the line when you first develop a standard, it gets harder still when you try to maintain that standard once it's got some good momentum in the industry. A standard that's revised too often and becomes a moving target really doesn't help anyone, but one that falls behind common usage has also failed.
PDF itself doesn't stand still -- a draft specification for version 1.5 has recently been released, but the current PDF/X-1a and PDF/X-3 standards are based on PDF 1.3, published way back in 1999. If the industry can survive the PDF specification being updated roughly every two years, then that's probably the right kind of interval between revisions of PDF/X as well.
That's why we've been working over the last couple of years to develop new revisions of the PDF/X-1a and PDF/X-3 standards ... this time based on PDF 1.4. The new versions were approved as ISO standards in late May this year, and are expected to be published in the Fall.
We think you'll like the results, especially as we've been able to take the opportunity to clarify some of the areas that we've had questions or disagreements over as vendors have developed products for the published versions.
At this point it should become clear why we've been recommending that the existing PDF/X standards be referred to as "PDF/X-1a:2001" and "PDF/X-3:2002" instead of just "PDF/X-1a" and "PDF/X-3." It gives a clear way to differentiate between those current versions and the new ones, which will be "PDF/X-1a:2003" and "PDF/X-3:2003" respectively. I can only say I'm sorry that we didn't dream up names that roll off the tongue more easily!
We expect the current flood of PDF/X-capable products to continue, with ever more functionality and ever-lower price points (PDF/X creation for less then $80, anyone?). At some point in the second half of this year you'll see some of those start to support the 2003 versions, too.
Planning the Migration
If you're already using PDF/X, or if you're expecting to in the near future, this section is for you. What you should do right now depends on whether you're creating files and sending them to other people, or if you're at the site receiving them.
The 2003 versions of the standards require a conforming reader to read all files that comply with either the 2003 or the previous version. Thus a PDF/X-1a:2003 reader must be able to read both PDF/X-1a:2003 and PDF/X-1a:2001 files. On the creation side, it's unlikely that you'll see any tools that only make 2003 files and not the currently published ones for some time to come.
If you're receiving the files:
Clarify your guidelines that describe what files you accept to state exactly which revisions of PDF/X you mean. If all you say is that you take "PDF/X-1a," don't be too surprised if some enterprising person sends you a PDF/X-1a:2003 file. Make sure your sales people know this information, too.
It's safe for you to upgrade your tools as new versions become available to support the 2003 revisions, because they'll still be able to read the older files. You'll then be able to handle whatever your clients send to you. Start planning those upgrades as soon as suitable and trusted products are shipping.
Don't forget to review your whole workflow before you say you accept 2003 files. Remember, you're opening the door to PDF 1.4 files (although most PDF/X files will continue to be PDF 1.3 compatible - see "Under the hood", below).
If you're sending the files:
Don't start sending 2003 files until the printers and publishers that you work with say they can accept them.
Keep an eye on new versions of the tools you use to create PDF/X files, and upgrade when you're happy with them. You don't need to rush into upgrading, though. Your printer or publisher will also be able to read the older files too, even after they've started to accept 2003 files.
Under the Hood
OK, so what's actually changed in the standards themselves?
One of the most obvious new features in PDF 1.4 was transparency. That's also one of the issues that we've had most queries about supporting in PDF/X. After much debate, the decision was taken to prohibit the use of partial transparency in the 2003 revisions of PDF/X. That was mainly because of very significant differences between the results from different transparency flattening engines in different products; you can flatten a file in different design programs and RIPs and get very different results -- all of them apparently correct according to the PDF specification. In that situation, how on earth can you expect a proof that the creator of a PDF/X file makes before transmitting it to be a reasonable prediction of the final printed piece?
This doesn't stop designers using the transparency functions in their design applications -- it just means that the transparency must be flattened before making the PDF/X file for transmission. That also means the flattening must be done before making the final pre-transmission proof, because that should always be printed from the PDF/X file you're about to send.
The other big issue in PDF 1.4 was JBIG2 compression, which can be quite effective for copydot scans. Even though the idea of encapsulating such data in PDF/X is somewhat against the spirit of the file format, we talked this one through for quite a while as well. In the end it was decided to prohibit JBIG2 -- not for philosophical reasons, but because of ongoing difficulties with access to intellectual property. All the patents flagged by the JBIG2 standardization group are theoretically available for free licensing, but getting those licenses signed can be very difficult and slow.
Of course, PDF 1.4 also added some new security options, but the PDF/X standards all prohibit encryption, so those new security options are also prohibited.
For historical reasons there's a PDF/X-1:2001 (without an 'a') conformance level as well as PDF/X-1a:2001 in the existing standards. To the best of my knowledge, it has not been implemented by any vendor, and rightly so. In the 2003 revision that conformance level has been removed.
Most of the other changes are simply clarifications. To take an example, PDF/X-1a:2001 requires that the creation date of the file be "filled in," and there have been disputes between validation tool vendors over the exact meaning of that phrase. We've finally answered that issue properly in the new standards.
Extending the PDF/X Family
While work on PDF/X-1a and PDF/X-3 was fast enough that we're now bringing out their second versions, they have a cousin that's taken a little longer to complete. PDF/X-2 is a superset of PDF/X-3 -- it includes all of the same support for color management, but goes one step further to enable an OPI-like workflow.
You might argue that with today's fast(er) computers, bigger hard disks and greater network bandwidth, there's no longer a need for OPI. If you're looking at what goes on inside a single workflow in one company that can be true, but remember that the PDF/X standards are designed to promote a reliable exchange of files between companies or sites. In that context, there are a variety of situations where there is value in the parallel processing that an OPI-like solution can bring -- where elements of a page may be worked on by different people in different companies at the same time.
A number of printers and publishers are considering the use of PDF/X-2 for constructing magazine pages from editorial and advertising, for instance -- allowing the final integration of all of the parts at the latest possible moment in the workflow.
You'll notice that I've carefully said "OPI-like" throughout the last few paragraphs. PDF/X-2 does not actually use OPI, but builds on the "reference XObject" structures in PDF 1.4 ... adding a little more robustness along the way. The practical upshots of this are two-fold:
All of the elements of the final page must be stored as PDF/X files in their own right. This may mean adapting image workflows to save scans as PDF rather than TIFF.
An OPI server solution that isn't specifically written to support PDF/X-2 will not do so ... or at least will not enforce the additional checks that the standard mandates in order to ensure that the correct referenced file has been found. In essence, the committee felt that current OPI servers don't provide the right combination of reliability and cross-vendor compatibility for file exchanges between multiple companies.
PDF/X-2:2003 was approved in May 2003, and is expected to be published in the Fall.
It shouldn't surprise you too much to learn that we're already planning the next revision of the PDF/X standards, this time to be based on PDF 1.5.
There's no need to panic, though ... or to put off plans for implementing the 2003 revisions. ISO standards tend to take rather a long time to develop, if only because there are very robust procedures in place to ensure that everyone can have their say about each standard. We're targeting a publication date some time around the Summer of 2005 for the next ones!
Debenu, released version 10 of their pioneering PDF SDK, Debenu Quick PDF Library. Available in single and multi licenses for Windows, Mac and Server development. In an important step forward for the SDK a range of great new innovative features and enhancements have been included.
OK, so you want to stamp your document. Maybe you need to give reviewers some advice about the document's status or sensitivity. This tip from author Ted Padova demonstrates how to add stamps with the Stamp Tool along with related comments.