10 Years Later & Stronger Than Ever: JDF Facilitates Printing Plant 'Communication'

Love it or not, JDF is the only standards-based approach to integration available for a printing industry bent on achieving ever-greater levels of automation.


New technologies keep early adopters on the bleeding edge, but 10 years of development brings the expectation the kinks have been worked out. That’s the case for version 1.4a of the Job Description Format (JDF) electronic job ticket specification. The latest update was published in December 2009 but is just now being implemented by vendors.

Compatibility with this maturing technology has been certified for 50 different applications, with the latest addition (as of press time) being Avanti’s Graphic Arts Management System V12.2. According to the Printing Industries of America, administrator of the JDF certification process, Avanti’s MIS application can share data with prepress workflow systems “using Job Messaging Format (JMF) communications, while transferring the appropriate JDF requirements for prepress workflow completion.”

The concept behind the acronyms has been a hot topic ever since computers arrived in print shops during the 1980s: allowing systems from different vendors to communicate job ticket and machine set-up information using a common terminology. Today, most MIS and prepress vendors have implemented both the JDF job ticket and the JMF communication protocol (for sending and receiving job information, including machine status info such as device speed and run counts), joined by an ever-expanding list of finishing equipment vendors and press manufacturers.

A History Lesson

That wasn’t always the case, however. Soon after the “Gang of Four” (Adobe, Agfa, Heidelberg, and MAN Roland) announced their intent to create an XML-based job ticket architecture at the Seybold Boston 2000 tradeshow, skeptics began to emerge from the woodwork. Criticisms that version 1.0 of the JDF specification was too vague, and that too much work was required to create cross-vendor implementations, missed the point: by basing JDF (and JMF) on the popular eXtensible Markup Language (XML), the Gang of Four was embracing a new approach in which user-developed extensions to the protocol would not only be admissible, but encouraged.

Shortly after the JDF effort was announced, guidance of the nascent specification was turned over to the International Cooperation for the Integration of Processes in Prepress, Press, and Postpress (better known as CIP4), a non-profit organization dedicated to the development of printing industry standards. Having already developed the Print Production Format widely used to communicate sheetfed press ink key presets, the CIP4 committee was able to coordinate compatibility between JDF and the printing industry’s previous efforts at computer integrated manufacturing including PPF, PJTF (Adobe’s Portable Job Ticket Format), PrintTalk, IFRAtrack, and PPML from PODi.

Drupa ’04 saw the release of JDF version 1.2 and the debut of JDF-enabled products from Adobe, Dalim, Enfocus, Global Graphics, Heidelberg, Océ, and others. While these first iterations were indeed focused on limited integrations between specific pairs of vendors, recent history has seen greater “plug-and-play” capabilities, thanks to the PIA certification program and the dedicated efforts of CIP4 committee members.

“JDF is a very powerful tool, but the specifications are very complex and intricate for printing companies to implement,” noted Marcus Pabsch, manoland’s VP of product marketing for sheetfed printing systems. “JDF allows any printing company to put together the right production environment.”

But not every open interface is built around an industry standard; some vendors simply publish their application programming interface (API) specifications and eschew JDF in favor of what has come to be known as “vendor XML.” These integrations may be less complex than JDF-compliant techniques but are only suited for connections between particular system pairings. Hammering out JDF interoperability requires more effort, but the result is a deeper integration across a broader pool of devices and vendors.

This content continues onto the next page...