Twenty Years of PDF/X – Part IV
Excerpt: Dov Isaacs discusses the issues and opportunities that the print publishing industry faces and how the PDF/X standard can help the industry in this installment of the ‘Twenty Years of PDF/X’.
About the author:
- 1 Twenty Years of PDF/X – Part IV
- 1.1 PDF/X in Retrospect
- 1.1.1 Successes
- 1.1.2 Issues, Opportunities, & Lessons Learned
- 1.1.3 Where PDF/X hasn’t worked yet, and why
- 1.1.4 Lessons for the future
- 1.1 PDF/X in Retrospect
This is a multi-part article looking into how PDF/X paved the way for future PDF standardization and how the PDF/X family of standards revolutionized the graphics art industry.
Part I: It Started with PostScript
Part II: PDF tames PostScript and publishing
Part IV: PDF/X in Retrospect
PDF/X in Retrospect
The twenty year history of PDF/X has yielded notable successes but at the same time has highlighted serious issues in both the industry and the process of developing standards.
The reliability of the end-to-end publishing process has significantly improved by use of the PDF/X standards especially when the PDF/X version most appropriate for the content and the production requirements is used. As an example, for content with color and/or transparency effects, use of a PDF/X-4-based workflow will generally yield more reliable and consistent results than a PDF/X-1a-based workflow.
The over two-decade experience of creating, evangelizing, and using the PDF/X standards has visibly demonstrated that the careful definition and use of well-defined subsets of the overall PDF specification for specific workflows is an appropriate strategy for successful use of PDF for specific purposes. PDF/A for archiving is one very notable example of another such definition and use of a PDF subset specification.
Issues, Opportunities, & Lessons Learned
The print publishing industry has been plagued by the almost glacial adoption of newer PDF/X standards that are much more appropriate for both the content being created and the available rendering technologies.
Content has changed. Color (as opposed to monochrome) predominates. Color beyond that which can be rendered by process CMYK colorants alone is increasingly common. Higher levels of graphical complexity, including use of transparency effects, is likewise common. Pre-flattening transparency and conversion of ICC color-managed content (typically RGB-based) to a particular device process color space (such as SWOP CMYK) yields PDF that is device-dependent (both in terms of colors and resolution) limiting ultimate choice of actual output device or even reasonable display on screens. Yet, PDF/X-1a with its DeviceCMYK and pre-flattened transparency model is still the most commonly used PDF/X version although all major graphics and layout software.
Rendering technologies have changed. Virtually all production RIPs and DFEs have fully and natively supported PDF/X-4 for over a dozen years. Complex graphical content in a PDF/X-1a file (all colors converted to process plus spot colors and all transparency pre-flattened) will not render with any higher quality or better performance than the equivalent PDF/X-4 file (with ICC color management and live transparency) to a PDF/X-4-capable RIP/DFE. Quality and performance often significantly suffer.
Four factors play into this slow rate of acceptance of PDF/X-4:
1. Education, and especially, continuing education
Education is critical for content creators, print service providers, and vendors of graphics arts and print production products alike. ISO committees can develop amazingly useful updated standards, but ignorance of fundamentals and advances in the state of the art for graphics and printing by practitioners make the availability and implementation of such standards irrelevant.
In a highly competitive, rapidly changing industry, the “if it ain’t broke, don’t fix it” Luddite attitude serves only as a lame excuse to continue to use outdated processes and procedures to both the customers and the service providers’ detriment in terms of time, cost, and quality.
3. Poor documentation and/or support
In conjunction with questionable default settings or even “how-to” and “best practice” tutorials, poor documentation exacerbates the education and complacency problems. In previous decades, we used to joke about RTfM, “read the fine manual”. Graphic arts content creation, as well as RIP/DFE control software, would come with documentation explaining the available settings and options of the respective products. Tutorials and white papers detailing best practices were readily available via downloads from the vendors. Such documentation and tutorials have at best been seriously cut back primarily due to cost-cutting and the mistaken perceptions by some vendors that they no longer need to cater to the print industry.
4. Blame the customer
If the customer is made responsible for converting all color to process CMYK plus spot colorants as well as for flattening transparency yielding PDF/X-1a, then if the printed output doesn’t meet the customer’s expectations, the print service provider can lay blame on the customer. This is one of the factors for major print service providers requiring customers to submit only PDF/X-1a files. What part of “service” do such print service providers not understand? Remedying this type of issue is an area where national and local print associations should take an active role.
Where PDF/X hasn’t worked yet, and why
Some PDF/X standards and conformance levels have effectively been ignored by the content creation applications as well as the overall graphic arts community and the print industry. These include PDF/X-4p and all the conformance levels of PDF/X-5. They are neither supported by any major graphic arts applications nor are we aware of any visible clamoring for such support. In these particular cases, the use cases presented by the standards developers simply didn’t match the real customer needs.
Then there is the situation with regards to industry support for creation of files conforming to the newest PDF/X version, PDF/X-6. Although the enabling standards including PDF 2.0, ISO 17972-4 (for CXF/X-4 spectral color data), and ISO 21812 (for production metadata) as well as PDF/X-6 itself have all been published for more than a year now. Although RIP/DFE support is available, at this point no major graphics applications have released support for PDF/X-6. There also appears to be a “chicken and egg” issue here. In order to implement and test a PDF generation software, you need to have software that can properly view and potentially diagnose the generated PDF. But to have the latter, you need to be able to generate the PDF. Perhaps this logjam will be remedied within the coming year, but until we have PDF/X-6 generation, some significant advances in the implementation of more advanced end-to-end print production workflows will be seriously stymied!
Once we do have industry support for robust creation and consumption of PDF/X-6, we will likely have some of the same issues as we currently encounter with industry acceptance of PDF/X-4.
Lessons for the future
Finally, there are certain key lessons that the last twenty plus years of PDF/X either have or should have taught us:
1. Cooperation between vendors is key
Cooperation between vendors leading to ISO standards is a major “win” both for the vendors and their customers. On the other hand, differentiating into incompatibility is a long term loss for both vendors and their customers.
2. There’s no substitute for technical education
Education and continuing education in the technical aspects (as opposed to the fun, creative aspects) of the graphic arts are critically important and must be addressed not only by print, design, and graphics communications academic programs, but also by vendors and print associations especially.
3. Implementation before standardization
There is often a big disconnect between the brilliant industry technology experts who develop standards and the ultimate support for same by the industry in general and specifically by the vendors those same industry experts represent. The vendors’ product managers who determine their company’s product features don’t sit around the table at standards meetings. Perhaps the standards development process should have a requirement for commitments to actually implement features by one or more vendors before canonizing within a standard. There is nothing sadder than a standard or major features of standards that are never actually implemented in products.