Just over 25 years ago, PostScript came into being. There was no industry standard page description language. A number of others existed, including ones from IBM and Hewlett-Packard (HP), but Adobe’s founders had a better idea; their language could be used to guarantee that no matter what printer is used, a page saved as a PostScript output file would print the exact same way. Fortunately for Adobe, Apple chose its language as the standard for its Macintosh computers, giving some legs to this fledgling standard. Most of us, however, could not understand the need for PostScript. Yet, software companies developing new technology in that era rushed to utilize this new standard lest they be left out. Without ever having become an International standard, PostScript—the PDF workflow—is the mainstay of the commercial and document printer.
While Adobe and PostScript started out as a closed system standard, its popularity allowed Adobe to provide open source information over time. So today, many vendors can provide PDF-compatible workflow components in an open system.
Continuing the story, just a short time later—circa 1984—proprietary formats in the other end of the business, the color separation world, came under attack. Color trade shops fought the vendors desperately to allow them to exchange data between competitive systems for backup production and load sharing purposes. An international committee was formed to create a Digital Data Exchange Specification (DDES), which would allow this exchange to take place. Since each vendor had proprietary data formats they were reluctant to share, DDES became essentially the least common denominator. It was a language based upon the most rudimentary information, but at least it worked.
Fast-forward again to the year 2000 and the same kind of issue becomes important once again. Myriads of different pre-press products—involved in the processes necessary to develop an integrated workflow from design through print and eventually finishing—didn’t work together to exchange information and simplify workflow.
This time the solution was something dubbed Job Description Format (JDF). This was so big, that in December 2002, The Seybold Report editors nominated JDF as one of The Ten Biggest Technology Stories of 2002.
On April 11, 2001, International Cooperation for the Integration of Processes in Prepress, Press, and Postpress (CIP4) announced the release of its first XML-based Job Definition Format (JDF) Specification. The 463-page specification defines the Job Definition Format (JDF) and its counterpart, the Job Messaging Format (JMF). It was said that JDF was an open, extensible, XML-based format built upon the existing technologies of CIP3’s Print Production Format (PPF) and Adobe’s Portable Job Ticket Format (PJTF). JDF had the ability to unify the pre-press, press, and post-press aspects of any printing job. It also provided the means to bridge the communication gap between production services and Management Information Systems (MIS). JDF was also touted as being able to carry out both of these functions no matter what system architecture was already in place, and no matter what tools were being used to complete the job.
Let’s fast forward now to 2007. Multiple recent studies indicate that very little utilization has actually been made of JDF in the marketplace. After all the hype, and all the demonstrations at the trade conferences, what is it about JDF that the users just don’t seem to get?
We think the problem arises from trying to force limited streams of compliance between products to integrate small pieces of a very large specification. Consortiums of vendors initially banded together to try to develop specific data handoffs that would enable their products to work together. But the fact remained, that two products could both be JDF compliant and they wouldn’t have a prayer of communicating.
Although there are multi-vendor solutions that work, most working solutions are offered with single vendor proprietary components. Vendors have invested a great deal to bring these vertically integrated solutions to market, but the average printer doesn’t have enough properly-integratable products. That is not to say that a significant number of printers have not signed on to JDF implementation, just that adoption has slowed significantly. Without significant help from its vendors, smaller and mid sized companies, the bulk of the market, and companies who do need the benefits of JDF to remain competitive in the current print marketplace, just don’t have the time or energy to adopt JDF.
Backing this up are some comments from the organizer of the Vue/Point Conference in 2005. "We deliberately did not run a JDF session, per se, because we felt it’s been overhyped and isn’t really there to the extent we’ve been promised. The evening roundtable was attended by maybe 75 people, but disproportionately by vendors. It would have been really interesting if we had more printers there. Jim Harvey [executive director of CIP4] really made the focus more on automation than JDF and barely discussed current interoperability capabilities, a sign to me that he realizes they need to pull back a little on their promises. It was a fun, animated discussion/debate, but in many ways it further supported just why we didn’t do a JDF session. We try to focus on today’s reality from the perspective mainly of midsized printers, and in that marketplace the JDF story is still a bit limited I think," says Mike Vinocur.
Worse still, as we move into the growth side of print—the digital print world—we find that the knowledge base about JDF and its benefits are even less understood. For the last 30 years, workflow has been more and more important in keeping offset printers profitable. While reviewing the kinds of owners that become new print franchise operators, and those most recently starting large format digital print shops, it has been amazing how many knew nothing about print, except that it was a profitable opportunity in the right niches.
They don’t have any of the background necessary to understand the importance of workflow. The first issue is how to keep the press busy enough to pay the bills. It is only after they become profitable that improving their internal processes becomes important. But, as more and more new shops are digital rather than offset, the knowledge base among them and their vendors about JDF declines significantly.
The recent February 2007 Print Industries Market Information and Research Organization (PRIMIR) study—Digital Printing Outlook in a Production Environment—provided further fuel to this argument. "Like general commercial printers, JDF usage is low among digital print providers. Even more noteworthy is the use of Universal Printer, Pre-, and Post-processing Interface (UP3I), which is literally nonexistent. No respondents in the research are using UP3I; only six sites plan to in the future. More education is clearly warranted if UP3I (JDF) is to be adopted by digital print providers."
Agfa, EFI, Heidelberg, Kodak, Xeikon, Xerox, and most of the software RIP companies have been big proponents of JDF. But, have you seen much from Gandinnovations, HP (except for Indigo), Inca, Mimaki, Mutoh, VUTEk, and the other large format printer vendors in the growing digital realm? Selling hardware seems to be their theme. After a printer is purchased, the customers quickly learn that they need more in terms of finishing and workflow, not just print capability, to grow and prosper.
And, for those who do understand, they seem to be happy with just asking their existing vendors to add more capabilities to their existing workflow processes, rather than to totally change workflow and perhaps even hardware to get the most out of a generic JDF implementation. We believe that this simplistic approach, which seems to work, is more and more in the cards. One production workflow vendor we know well has recently been asked by its largest customer to add accounting, estimating, and job costing information to their existing process. If that is accomplished, the vendor has additional functionality to offer, and the customer gets his needs accomplished, but they do it in an orderly process. Even here, with a large customer, tailored and open, rather than generic and open, solutions seem to be preferable.
Much like what transpired with the adoption of PostScript, we believe that home-grown solutions will become more and more important for existing installations, rather than the more painful adoption of JDF. Standards are great if they work. Yet, products that work grow at the speed of the market. Because they fulfill the customers’ needs, they are easily implemented.