Twenty Years of PDF/X – Part II

Twenty Years of PDF/X 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 III: The continued development of PDF/X standards

Part IV: PDF/X in retrospect

Part II: PDF Tames PostScript

In the early 1990s, Adobe’s co-founder Dr. John Warnock recognized that the strengths of PostScript for publishing were in fact the weakness of PostScript as a medium for efficiently communicating visual material between different computer systems and rapidly accessing, displaying, and printing such material on any system including the typical desktop systems of that time. He described his vision of an Interchange PostScript (IPS) that essentially was the minimally necessary graphical essence of PostScript, stripping away the high overhead and lack to deterministic behaviour of a general-purpose programming language but adding full page independence. The Adobe Camelot Project became the Adobe Carousel Project that yielded the Portable Document Format (PDF) and the first version of Acrobat in 1993.

By PDF version 1.2 (Acrobat 3.0, late 1996), PDF had enough of the PostScript imaging model features implemented to be considered as a viable alternative to PostScript for not only screen display of graphics, but for print publishing as well. With PDF version 1.3 (Acrobat 4.0), the PDF imaging model surpassed that of PostScript with support for ICC color management. PDF version 1.4 (Acrobat 5) added transparency to the PDF imaging model, even further differentiating PDF from PostScript. Comparing PostScript with PDF:

In fact, PDF did tame PostScript in terms of functionality, reliability, and performance. The print industry was beginning to take PDF quite seriously as a potential replacement for PostScript. Some leading-edge print service providers were in fact beginning to accept “print ready” PDF files from trusted customers as digital masters for the print process. However, in the early days of PDF, the print process typically involved converting the PDF file to PostScript which in turn was submitted to the actual RIP.

Taming PDF for Publishing – PDF/X to the Rescue

PDF by itself posed challenges for print publishing, especially as the PDF specification expanded in size and complexity.

• The PDF imaging model had features that were not yet mainstream and for which both content creators and print service providers felt uncomfortable in their use either due to lack of training and confidence or sketchy PDF implementations. Such features included ICC color management (i.e., colorants beyond either DeviceCMYK, DeviceGray, and spot colors) and “live” (unflattened) transparency.
• Some image compression techniques such as JPEG2000 were either not yet fully or properly supported in some PDF creation and/or rendering implementations. In the case of LZW compression, there were intellectual property concerns.
• PDF features beyond simple imaging could lead to ambiguous interpretation when rendering:
  • Annotations – Render or not render when printing?
  • Multimedia – Sounds, movies, animations, etc. – Ignore? Print the annotation, if any, representing the multimedia object? One is certainly not going to “print” the sound, movie or annotation on a printing press!
  • Embedded PostScript via PostScript XObjects – Although such PostScript would supposedly be output to a PostScript RIP in the case of PDF being rendered via conversion to PostScript, use of such embedded PostScript is not necessarily reliable, makes the PDF file highly device-dependent, and is totally useless with RIPs that directly render PDF.
  • JavaScript – Use of JavaScript (ECMAScript) within a PDF file provides the capability of dynamically modifying PDF content “on the fly” unless you establish some strict rules and limitations on how PDF RIPs process JavaScript, if at all. JavaScript can effectively add back some of the uncertainty of PostScript into PDF!
• Referenced External Content – Use of Reference XObjects to assemble content not only adds a degree of latency but potentially unreliability to print workflows, if access to the external content is blocked or if that content unexpectedly changes.

With the above serious issues, there was no means by which participants in a workflow could ascertain whether a PDF file complied with “reliability standards.” The process was fraught with uncertainty.

Content creators and their print service providers needed to be able to provide and receive PDF files with confidence that such files would print per the content creator’s expectations without errors, unexpected “surprises,” or the need for the print service provider to rework such files. The stakeholders were looking for a means of “blind exchange” of PDF for print publishing.

The response to these challenges was the development of the first PDF/X-1 standard (where the X stands for the X in “blind exchange”) by CGATS (Committee for Graphic Arts Technologies Standards) and published by ANSI (American National Standards Institute) in 1999. This PDF subset standard was based on the Adobe PDF 1.2 specification and did not have significant adoption. Reflecting an international interest in PDF/X, the development of the PDF/X standard moved to ISO (International Standards Organization) Technical Committee ISO/TC 130, Graphic Technology which has had ongoing responsibility for further development of the PDF/X standard.

PDF/X is represented as multiple parts of ISO standard 15930 – Graphic technology — Prepress digital data exchange — Use of PDF. To quote the introduction to ISO 15930-9:2020 (PDF/X-6):

ISO 15930 (all parts) defines methods for the exchange of digital data within the graphic arts industry and for the exchange of files between graphic arts establishments. It is a multi-part document where each part is intended to respond to different workflow requirements. These workflows differ in the degree of flexibility required. However, increasing flexibility can lead to the possibility of uncertainty or error. The goal throughout the various parts of ISO 15930 has been to maintain the degree of flexibility required while minimizing the uncertainty.

In the context of the PDF specification, the “parts” refer to what laymen would otherwise view as the different PDF/X standards such as PDF/X-1a, PDF/X-3, PDF/X-4, etc. Within the “parts” there may be multiple compliance levels such as PDF/X-6, PDF/X-6p, and PDF/X-6n all within the overall ISO 15930-9:2020 PDF/X-6 specification.

What is in common for all the PDF/X specifications – the “parts” of ISO 15930 – and the compliance levels thereof is that to achieve a level of exchange that avoids any ambiguity in the interpretation of the file, they each specify:

• The subset of a particular full PDF version upon which the particular PDF/X version is based such as Adobe PDF 1.3, Adobe PDF 1.6, ISO 32000-2 (PDF 2.0), etc.
• An enumeration of PDF features that may not be used at all, which features may be used in limited circumstances, limitations on feature usage, and specific requirements for use of allowable features. The limited set of PDF objects that are permitted to be used is identified as well as restrictions to the use, or form of use, of those objects, and/or keys within those objects.
• Method of identification of the file as conforming to a particular PDF/X standard (although not a certification of actual compliance).
• Additional requirements such as Output Intents, font embedding, page geometry boxes and ordering thereof, etc.

ISO 15930-1:2001 defined two compliance levels of PDF/X-1, PDF/X-1 and PDF/X-1a supporting blind exchange of DeviceCMYK, DeviceGray, and separation/DeviceN (spot color) text, vector, and raster image data based on Adobe PDF 1.3. There were three differences between the two compliance levels. PDF/X-1a disallowed the use of Open Prepress Interface (OPI) references via embedded files, disallowed encryption, and required a GTS_PDFXConformance key with a value of (PDF/X-1a:2001) in the file’s Info dictionary.

Of the two compliance levels of ISO 15930-1:2001, PDF/X-1a was the true success story due to its relative simplicity and ease of use. The requirement of support for OPI via embedded files (including non-PDF file formats) as well as encryption both for PDF file creation and interpretation, simply made the PDF/X-1 compliance level a non-starter in terms of both implementation and desirability.

PDF/X-1a was very rapidly accepted by the print publishing community, content creators, publishers, and print service providers alike, as publishing software application and RIP developers provided and publicized PDF/X-1a support within their products. Having demonstrated that a carefully-defined PDF subset could indeed significantly improve end-to-end publishing workflow reliability, PDF/X had indeed tamed PDF and hastened the migration from PostScript to PDF with the arrival of the 21^st century.

The success of PDF/X was noticed by other PDF stakeholders, especially the community of archivists exploring use of PDF for reliable long-term preservation of electronic documents. ISO Technical Committee ISO/TC 171, Document management applications, Subcommittee SC 2 developed and subsequently published the first part of the ISO standard 19005 – Document management — Electronic document file format for long-term preservation. ISO 19005-1:2005 Part 1: Use of PDF 1.4 (PDF/A-1) was published in late 2005 and has over time gained tremendous traction in the document archiving community.

Twenty Years of PDF/X continues with the continued development of PDF/X standards.