American Printer's mission is to be the most reliable and authoritative source of information on integrating tomorrow's technology with today's management.
Sep 1, 2003 12:00 AM
JDF is a format/standard based on eXtensible Markup Language (XML) and built on the existing technologies of CIP3's Print Production Format (PPF) and Adobe's (San Jose, CA) Portable Job Ticket Format (PJTF). (See “Standards update,” Oct. 2002.)
Adobe, Agfa (Ridgefield Park, NJ), Heidelberg (Kennesaw, GA) and MAN Roland (Westmont, IL) were responsible for the initial development of JDF, but in 2001, the companies transferred JDF activities to the International Cooperation for the Integration of Processes in Prepress, Press and Postpress (CIP4), an international standards body located in Switzerland. (CIP4 is the successor to CIP3, a joint initiative of vendors launched at Drupa 95.) JDF 1.2 is currently being finalized. We asked the CEO of CIP4, Martin Bailey, to bring us up to date on the latest developments.
JDF 1.2 addresses transmission of digital assets and preflight as well as compatibility among components from multiple vendors. Can you provide some specifics?
The structure of JDF is built around “processes” and “resources.” A process is an operation performed on digital data, such as a PDF file or an imposition design, or on a physical item, such as a lift of paper. A resource is the digital data or physical item itself. Existing processes in JDF include RIPing, conventional printing, trimming, etc.
In JDF 1.2 we're defining a new process, Asset Delivery, which allows control over the movement of digital files between sites. A second new process, Preflighting, controls preflight processes on digital files. The two may be combined, allowing robust delivery of digital files to be tightly integrated into the workflow.
These two processes are important, not just because they extend the coverage of JDF further upstream, but also because they are the first processes in a JDF-controlled workflow that often involve two separate companies. We've always had the ability to spawn and merge JDF files for subcontracting and other processing by multiple service providers, but nothing in JDF 1.1 [supported] two companies acting on the same process in such a tightly linked cooperation.
We're also working on interoperability conformance specifications (ICSs). There are two classes of ICSs. One defines a number of “base conformance” profiles for how products exchange data through JDF. The second defines “workflow” profiles specifying which processes and what configurations must be supported. Essentially both list which bits of JDF a product has implemented. There are workflow ICSs being developed for digital printing, prepress software and other sections of different workflows.
That may sound a bit complicated, but the result will be a table with the base conformance profiles in one direction and the workflow profiles in the other. Two products with ticks in the same cell of that table will work together.
We're providing support for vendors to test their products with those from other vendors so that any problems that creep in because two people read the spec differently are discovered before products ship.
Many vendors say that Drupa 2004 will be the big coming-out party for JDF. What do you think?
We're getting exactly the same message — the 2004 show will be remembered as “the JDF Drupa.” Of course, it will take a while before most companies are working with complete JDF workflows, because nobody will throw out all their existing equipment and replace it. But the natural process of software upgrades and a plethora of third-party after-market products will mean that most people will certainly be moving in that direction very soon.
Although JDF is often perceived as being plug-and-play, that's not currently the case. Will it eventually be?
Working for a prepress software manufacturer, I can tell you that we test the PDF that we create with many PDF readers, and we test other vendors' PostScript and PDF with our RIP products. JDF is no different in that respect. But the JDF format is not so trivial that vendors can guarantee that it will work with all other products straight away. After a bit of experience, we likely will see a limited plug-and-play capability appearing.
One of the most difficult things will be providing good, understandable data about which products should work together. Some combinations will obviously be incompatible — an imposition program optimized for gravure cylinders with a laser printer, for instance — but other issues may be more subtle.
Remember that JDF provides a structured method for carrying data between products. Incompatibility in JDF handling is going to cause far fewer problems than matching up the functionality of those products themselves, especially when we're talking about updating existing products for JDF. It's like assembling a jigsaw puzzle where each part has been provided by a different vendor. It's almost inevitable that combining early versions will leave gaps in the overall picture, and equally inevitable that the vendors will work hard to fill those holes as quickly as they can.
We've previously addressed the importance of vendors and users working together to develop standards. Does the average printer understand JDF's potential benefits?
A user who hasn't yet been shown the value of JDF probably won't be willing to invest any time or effort in providing input to CIP4. We're beginning to get the message out, directly from CIP4, via vendor road shows and through conferences. It's a big task, but [we're making] progress. Our new executive director, Jim Harvey, is extending those educational efforts.
We're getting some user input, but most of that is from the largest print companies. That's definitely important, but a five- or 20- person print company has different needs that we must also address. We're currently relying on our vendor members knowing their own markets, which gets us a long way. But we'd like to hear more from smaller users.
What's next on the JDF agenda?
Over the next few months we'll be finalizing JDF 1.2. Through 2004, a lot of the emphasis will be on getting real product out in real print companies and making sure everything works well together, including finishing the ICSs so that users can easily determine which products are designed to be fully compatible.
Work has already started on JDF 1.3, including a group that's developing the requirements for advertising workflows in newsprint and publication.
JDF may help printers achieve unprecedented levels of process automation. But first they've got to understand the basics. Here are some helpful pointers.
JDF is an XML-based specification for process automation in the printing and publishing industries. Essentially, it's an agreement between printing and publishing organizations on how job information is organized and exchanged.
It's a collection of information that stays with a job throughout its lifecycle. Even though this information may at times reside in the databases underlying various workflow and management systems, the JDF specification provides a model for organizing that information and exchanging it between different systems.
A JDF job ticket may originate with a customer's production files or purchasing documents in electronic format. As shown in Fig. 1, the information may be added to a JDF job ticket as it moves from the customer's buying process, through estimating and scheduling. By the time the job goes into production, the job ticket will contain enough information to automatically drive JDF-enabled devices.
Each job is described using well-defined processes and resources (see Fig. 2). Every process (such as conventional printing and scanning) has a set of inputs and outputs called “resources” because the output of one process is the input to the next process. Resources include both physical materials (such as ink or plates), and data about the job, including processing instructions and job parameters.
Processes and resources are used like a set of building blocks — JDF provides a common language as well as a defined way of describing what is required from input and output systems from different manufacturers. A JDF-enabled workflow and management system enables full-process automation since it can determine when everything a process requires is ready to go and then set that process in motion. Jobs can be automatically routed to available devices, and, when new jobs come in, workflows can be automatically configured based on information in the job ticket.
It's an open-device command language included in JDF. JMF may be used by workflow and management systems — or even other devices — to query a device or provide processing instructions. New JDF-enabled systems, software and equipment — ranging from proofing systems to bindery and labeling equipment and everything in between — will support JMF. Legacy systems can be updated by adding a new JMF controller module.
Notification, query support, command support and submission support. Production and IT managers must determine which level of support is the best fit for their automation plans. Devices that support notification provide unidirectional messages that inform the controller when they begin and complete execution of some process within a job. At level two, query support, devices respond to requests from other devices by communicating status information such as current job progress. Level three, as its name implies, refers to devices that can process commands. Level four, submission support, encompasses devices with controllers that accept JDF jobs via HTTP and support MIME multipart documents.