In Search of PrintTalk and JDF -- McIlroy

I intended to devote this column to an exploration of the PrintTalk specification and to JDF (the Job Definition Format).

I got the idea when I opened the April issue of Printing Impressions and noticed an advertisement for PrintTalk (placed just below my column). The ad listed a bunch of sponsoring vendors, and had the headline "Demand PrintTalk-enabled Solutions from Your Suppliers."

I went to five or six of the Websites of the vendors listed in the ad and searched for a mention of PrintTalk. I couldn't find one.

The ad for PrintTalk lists a Web site—www.PrintTalk.org. There I learned that PrintTalk "is a community formed by print management systems and e-commerce companies to define a 'best practice,' common and open communications interface (sic) between their products. The PrintTalk implementation will support use of the broadly published, proposed Job Definition Format (JDF) standard and Commercial eXtensible Markup Language (cXML). As part of the group's activities, it will seek to have its work recognized as an implementation of the proposed JDF standard. The PrintTalk interface specification will be distributed free of any license fees or royalties, in order to address the need for end-to-end connectivity in the printing industry. NPES serves as secretariat to PrintTalk."

Oh, oh: a spec formed by e-commerce companies. I looked at the sponsorship list again. Two of the listed sponsors are out of business, Impresse and MediaFlex. Not a good sign. Further exploration of the site turned up a few background documents, most of them dating back to last September (about five years ago in Internet time!).

I saw that PrintTalk is based on JDF, so I searched the sponsor sites for a mention of that spec. No luck. I'd heard that JDF had a separate site. I tried www.JDF.org. Nope, that's the site of the Juvenile Diabetes Research Foundation International.

A Google search under "JDF job definition format" brought me to "www.job-definition-format.org."

That site, in turn, redirected me to "www.cip4.org." Ah, yes. CIP4. That's the old CIP3 group. CIP3 stood for "International Cooperation for Integration of Prepress, Press and Postpress." As I recall the fourth "p" stands for production. Nope, got that wrong; it stands for processes. I just found the definition on the CIP4 site: "The International Cooperation for the Integration of Processes in Prepress, Press and Postpress." Kind of rolls off the tongue.

Whew! This is exhausting me already. And we still don't know what the standard does.

Let's try the CIP4 Website for answers. What is JDF ?

"JDF is a comprehensive, XML-based file format/proposed industry standard for end-to-end job ticket specifications combined with a message description standard and message interchange protocol. JDF is designed to streamline information exchange between different applications and systems. JDF is intended to enable the entire industry, including media, design, graphic arts, on- demand and e-commerce companies, to implement and work with individual workflow solutions. JDF will allow integration of heterogeneous products from diverse vendors to seamless workflow solutions."

Okay. We're getting somewhere.

"The most prominent features of JDF are: Ability to carry a print job from genesis through completion. This includes a detailed description of the creative, prepress, press, postpress and delivery processes. Ability to bridge the communication gap between production and Management Information Services. This ability enables instantaneous job and device tracking, as well as detailed pre- and post-calculation of jobs in the graphic arts.

Ability to bridge the gap between the customer's view of product and the manufacturing process by defining a process-independent product view, as well as a process-dependent production view of a print job. Ability to define and track any user-defined workflow without constraints on the supported workflow models."

Wow! They're trying to create data and workflow standards for the entire graphic arts process, for the first time bridging everything from creative to delivery! I like it.

It's based on XML—I know you'll recall from my column last year ("What is XML, and Why Should You Care?" March 2000)—which is both a way of tagging content and a way of encoding information about processes. XML is proving to be a widely supported standard across the publishing and e-commerce communities. Given the intention to have JDF "streamline information exchange between different applications and systems," it makes a lot of sense to use XML for encoding the data.

Intrigued, I moved further through the site until I reached "the JDF Specification Version 1.0 is available now." I downloaded the entire 3MB, 463-page document.

A great spec, no doubt. But could it be a little over-specified?

Just this morning I was reading a fascinating and altogether irreverent broadside in the new Seybold Report. The piece, written by Dan Margulis and Chris Murphy, takes a (very) critical look at the other great recent graphic arts standard—ICC color management. The authors' conclusion is unmistakable:

"Despite a decade of hype about how universal adoption will be as rapid as it is inevitable, the concept loosely known as color management isn't even close to becoming mainstream." Ouch!

As one of the early supporters of color management, this stung me. The article goes on to catalog color management's failures: no support from large publishers or service providers, no support for RGB workflows, including "device independent" RGB, and little support for embedded ICC profiles.

The article concludes that "anybody suggesting that implementing ICC color management is easy, or using the phrase pushbutton color, should be condemned to press washup duty on the overnight shift for three years." Ouch again.

The authors suggest that the ICC color standards group has to accept a portion of the blame for color management's failure. As we move into the new JDF/PrintTalk era, I wonder if we'll have any better luck with these ambitious and complex overlapping standards.

Don't get me wrong. I support standards. I support workflow automation. I think that the intentions behind these groups are honorable, indeed. But looking at the roll-out thus far, and considering the scorecard on color management, I think we've got a long decade ahead on the workflow automation road.

—Thad McIlroy

About the Author
Thad McIlroy is a San Francisco-based electronic publishing consultant and author, and serves as program director of Seybold Seminars. He welcomes comments at thad@arcadiahouse.com.