I believe DPart is one of the most important new features in PDF 2.0. DPart is page based metadata in a PDF file, stored in a hierarchy to group pages into “document parts”. From a prepress point of view, it can be the most important feature – together with page based output intents. In combination, they are powerful tools for automation, for page based automation. Page based automation allows for bringing even more intelligence into workflows, for performance improvements and possible integration of print and post print steps into automated workflows.
DPart is not new in PDF 2.0, it was invented in PDF/VT-1 for variable data print and later taken over into the PDF 2.0 specification. Up until recently, it was not frequently used, but I learned from support that this has changed with some success: As said DPart structures can identify pages as belonging to parts (or “records”) and some output devices use information about such parts to optimize caching. E.g. if a PDF has numerous invoices with varying page numbers, an output device (DFE, RIP) can take advantage of knowing where an invoice starts to cache images from that start page for all other such start pages. We have learned in support that in some applications this allows for a performance boost of upto 10 times.
Such a performance boost is impressive; however, it is not the end of the story. Only the most basic information of the DPart structure – where parts start and end – is used here. But DPart structures can also contain more information, “real” metadata: It may add production parameters to pages and since DPart is based on a hierarchical structure (parallel to the pages structure) it is easy for a processor to identify and extract pages for processing that have certain metadata parameters. That means a big PDF with various pages may easily be split into parts and selectively processed on different devices.
An accompanying standard, Print Product Metadata (ISO 21812), defines standard “field names” and values for such DPart metadata. This closes a missing link in DPart structures to allow for interoperability between devices and workflows; in PDF 2.0 only the syntax for DPart is defined. The standard field names and values are in Print Product Metadata inherited from an old prepress companion, JDF, in fact from its more modern brother XJDF, which makes sure that all requirements that have been identified are covered.
It is now possible to define in a PDF structure e.g. which pages are to be printed black and white, which are using full color and what finishing is required for what pages – and this can be done in interoperable ways.
You may now say, that it may take long until file creators add such production information into PDF files. But I believe the industry does not have to wait for this: The printer’s MIS system could – instead of creating jobtickets – as well embed such production information into the PDF file, making it easy for such information to travel with the PDF through the workflow and at the same time to control its way via its data.
We at callas thought about what we could do to facilitate the introduction of these powerful technologies, DPart and Print Product Metadata -somehow hidden in the PDF specification. During our own implementations we saw that – even if DPart metadata is intended to control machines and is usually not consumed by humans – during implementation you need a tool to visualize DPart metadata structures. And that is why we developed “callas pdfDPartner”, a free tool available from our website for everybody interested in DPart structures
In our recent release, pdfToolbox 12, we introduced a way to add DPart record information to an existing PDF file. It can also analyze and export DPart structures so that it is prepared to extract all information needed to control PDF processing.
Want to learn more? Here are some references: