Outlook: Future ISO Standards based on PDF 2.0

Future ISO standards based on PDF 2.0

PDF 2.0 consolidates all extensions which have been introduced with various PDF ISO standards in recent years. On the other hand, new revisions of existing PDF standards are currently under development which will be based on PDF 2.0. This page provides an overview of the standards development. Unless noted otherwise, none of these standards has been published yet.

PDF/A-4

PDF/A-4, to be defined in ISO 19005-4 and tentatively also called PDF/A-NEXT, will be based on PDF 2.0. While PDF/A-2 and PDF/A-3 each comprised three different conformance levels which tended to confuse users, PDF/A-4 simplifies things and eliminates conformance level designations for tagged vs. untagged documents. A PDF/A-4 document may or may not contain tags. Unlike previous parts of the standard no dedicated conformance level is required for tagged PDF/A-4 documents, thus eliminating the a/b conformance level distinction of PDF/A-1/2/3. Similarly, a PDF/A-4 document may or may not contain file attachments. The attached files must conform to PDF/A-1, PDF/A-2 or PDF/A-4. For each file attachment its relationship to some part of the main document must be specified with the AFRelationship key.

While abandoning the previous a/b/u conformance levels, PDF/A-4 introduces two new conformance levels:

  • PDF/A-4f allows non-PDF/A file attachments (in a similar way PDF/A-3 extends PDF/A-2).
  • PDF/A-4e is targeted at the engineering community. It is slated as successor of the existing PDF/E-1 standard ISO 24517-1 which is based on PDF 1.6. The previous plan to define a new flavor PDF/E-2 as ISO 24517-2 has been canceled. Instead, PDF/A-4e adds RichMedia annotations for 3D content in U3D or PRC format to the base PDF/A-4 format.

PDF/UA-2

PDF/UA-2, to be defined in ISO 14289-2, is the successor of PDF/UA-1 and will be based on PDF 2.0. This means that the new PDF 2.0 tags as well as structure namespaces can be used, and that the strict PDF 2.0 tag nesting rules apply to PDF/UA-2. While PDF/UA-1 includes some requirements regarding the use of heading levels, these requirements will be dropped from PDF/UA-2. Also of interest: features which are deprecated in PDF 2.0 are not allowed in PDF/UA-2.

All navigation targets inside a document, e.g. link destinations, must be expressed with the PDF 2.0 method of structure destinations.

PDF/UA-2 introduces the concept of Additional Accessibility Declarations (AAD) which describe the document’s compliance with other accessibility specifications. AADs are stored as properties in the XMP metadata.

PDF/X-6

PDF/X-6, to be defined in ISO 15930-9, will be based on PDF 2.0 and defines the main PDF/X-6 flavor for complete exchange as successor of PDF/X-4. The new standard also defines two formats for partial exchange:

  • PDF/X-6p for documents with an external output intent ICC profile (successor of PDF/X-4p based on PDF 1.6);
  • PDF/X-6n for n-colorant profiles (successor of PDF/X-5n based on PDF 1.6).

There are no plans for successors to PDF/X-5g with external graphical content and PDF/X-5pg with external profile and content as these formats didn’t find adoption across the industry.
PDF/X-6 takes advantage of the new PDF 2.0 feature of page-level output intents. This feature is useful for documents where individual pages are intended to be printed on different output devices, e.g. a collection of mailings where the cover page is printed in black and white only, while the inner pages are printed in color.

Spectral data (CxF) may be present in a PDF/X-6 document, but there are no specific regulations regarding its use, except that such data must not conflict with the output intent ICC profile.

PDF/X-6 allows annotations and form fields inside the visible area of a page, which is not allowed in earlier parts of PDF/X. Per PDF 2.0 requirements, however, all annotations require appearance streams, and the appearance streams themselves must adhere to PDF/X requirements to ensure reliable rendering.

PDF 2.0 introduces a new control for specifying Black Point Compensation for individual graphical contents. PDF/X-6 mandates that Black Point Compensation be enabled in the absence of an explicit setting.

PDF/VT-3

PDF/VT-3, to be defined in ISO 16612-3, is the successor of PDF/VT-1. It will be based on PDF/X-6 (any conformance level) and therefore PDF 2.0. At the core of PDF/VT there are rules for dealing with repeated contents and transparency. The respective requirements for encapsulated XObjects in PDF/VT-1 relate to the use of transparency on any page in the document (not only on the page where the XObject is used), which places a big burden on some types of software. In contrast, the PDF/VT-3 rules relate only to the use of transparency on the same page which greatly simplifies processing.
Multi-file exchange and stream delivery have been abandoned for lack of industry support; therefore no successors of PDF/VT-2 (which is based on PDF/X-4p, PDF/X-5g, or PDF/X-5pg) and PDF/VT-2s, which defines a MIME package containing one or more PDF/VT-1 files or PDF/VT-2 file sets, will be specified.

PDF/VCR-1

PDF/VCR-1, which has already been published in 2017 as ISO 16613-1, is a new standard aimed at Variable Content Replacement (VCR). It is targeted at high-volume production of personalized items such as credit cards, loyalty letters, individualized printing e.g. for pharmaceutical product packaging with lot number and expiry date, or serialized tickets.

A PDF/VCR-1 document is based on PDF/X-4 or a newer part of ISO 15930. Therefore, PDF/X-6 and PDF 2.0 can also be used as the base format for PDF/VCR.

In a sense, PDF/VCR offers what some people erroneously believed PDF/VT to deliver: while PDF/VT transports final contents, a PDF/VCR document constitutes a template with placeholders. The template is merged with variable data at ripping time, thus creating the final document. The placeholders are marked in the template with techniques taken from Tagged PDF with some custom extensions. The variable data, called a data sequence, is provided in the form of a CSV file per RFC 4180.