Product Definition in PDF

This page gives you a short summary of the PDF print product metadata technology. With this fairly new technology, product and production descriptions can be entered into a PDF file as metadata. This means that layout data and production data are merged in a single file.


The topic was taken up by ISO and published under ISO 21812-1:2019 Graphic technology — Print product metadata for PDF files.

PDF Print Production Metadata

With PDF Print Product Metadata, artwork and product/production data are stored in one single file

Generally, JDF or XJDF contain the product intent of a print buyer. That is, both formats can hold properties of the requested product, such as

  • type of product
  • printing substrate
  • binding intent
  • type of inks to be used
  • number and dimensions of pages
  • delivery details

This data is normally stored in XML. Since 2019, there is another way to store this kind of data, namely inside PDF. Thus, a PDF file may contain not only the artwork data but also the product description. This concept goes far beyond considering PDF just being a page description language (PDL).

The idea is that the print buyer stores the product intent inside PDF, either by entering the data directly in some layout program, which generates the PDF, or indirectly by using a web-to-print system/customer portal, that writes this metadata into the PDF. When such a PDF file reaches the print provider, it can then be split up in two; in artwork (PDF) and in product intend data (JDF/XJDF). Thus, there is no need to change the production workflow at the print shop. On the other hand, the advantage of such an approach is that both artwork data and product intent data are stored in one single file during transmission between print buyer and print provider. There is no need any more to link the artwork and the job ticket at the printer provider's site.

Internally, PDF stores all its objects in a tree structure. 2010 Adobe introduced PDF/VT for variable data and transactional (VT) printing. In this context they created another branch for document parts (DPart tree) in parallel to the PDF page tree. This allows document parts to be identified within a PDF file. Each DPart object can also be associated with its own Dictionary Document Part Metadata (DPM), which in turn can hold application-specific information about the document parts. The standard defines only the DPM structure that can be populated with basically anything. This provided the ability to define specific keywords and values for product and production details and refer these to subsets of pages in the PDF file.

ISO's Print Product Metadata standard 21812-1:2019 defines keywords and values based upon concepts specified by XJDF product intent. These can be embedded into the DPart object tree in a compliant PDF document to provide detailed product description such as binding-style, media-type, and other characteristics of the finished product.

DPart and DPM structures are stored in PDF dictionaries. A dictionary in PDF is a table containing one or several key/value pair(s) – like a normal dictionary for languages. Each dictionary is wrapped by double angle brackets, that is <<key value key value…>>. Unlike a normal language dictionary, however, the value of a PDF dictionary can be an (almost) arbitrary object, for example another dictionary. Each dictionary represents a level in the hierarchy for DPM structure.
The keywords are easy to recognize: they all start with the letters /CIP4_. If a value is a String, it’s surrounded by round bracket. For example, /CIP4_BindingType(SaddleStitch) determines that the product should be saddle stitched.

A Document Part Metadata (DPM) contains the product details of a print job