American Printer's mission is to be the most reliable and authoritative source of information on integrating tomorrow's technology with today's management.
Aug 1, 2004 12:00 AM
Let's start with the basics. JDF is an acronym for Job Definition Format. JDF is owned and managed by the International Cooperation for the Integration of Processes in Prepress, Press and Postpress (CIP4). CIP4 is the successor of CIP3, which started in 1995 as a joint initiative of vendors for the graphic-arts industry. Since then CIP3 has developed the Print Production Format (PPF), which can be found today in many applications that connect prepress devices to press and bindery equipment.
What does JDF do? Given all the press coverage and the buzz at Drupa, you may be surprised to learn that JDF itself doesn't actually do anything. JDF is neither a machine nor a software product. You can't buy a shrink-wrapped box of JDF and install it. So what is it? JDF is a data-interchange format. It is a way for one system to output data in a format other systems can understand.
Print service providers won't “implement” JDF any more than you would implement a global system for mobile communication (GSM) when you buy a new cell phone. You just buy a phone. You probably don't even stop to wonder whether your new Nokia phone can be used to call someone who owns a Siemens phone. You certainly don't worry that the cell tower transceiver, made by Motorola, can't pass your call through. But the reason the equipment from these various vendors works together is that they all use a common data interchange format when writing the software that handles interdevice communication.
Unfortunately, the graphic-arts industry scenario isn't quite as straightforward. All systems don't necessarily work together. The only way to ensure employees aren't routinely required to re-enter data from system to system is to buy equipment from vendors that have formed commercial agreements and cooperated with other vendors on systems communication, or to pay an integrator to write custom software that translates the different data formats.
JDF rapidly is emerging as the answer to this problem. By providing a common format that all vendors can enable their systems to read and write, JDF will allow the integration of systems from multiple vendors into a single, logical system. By smoothing the flow of data from one process to the next, the way the factory works can be improved.
At this point you might be thinking “Hey, isn't that what CIP3's PPF does? Why do we need JDF?” But JDF takes a broader view than PPF. It models everything from the product to be priced, through the settings for the individual machines, and the capture of the activities and actions taken during production.
Which brings us to the essentials of JDF. As you may know from discussion with vendors' sales and marketing people and your own in-house IT professionals, JDF is an extensible markup language (XML). Perhaps your IT person has casually said something like this: “Although CIP4 provides a schema, the complexities of JDF are not fully represented by that schema and thus post-validation processing is required.”
If you didn't quite understand that last part, don't worry. You can leave that level of detail to your vendors, system integrators and IT gurus. Nonetheless, it does help to have at least a basic grasp of what the engineers (or, as we are often called, geeks and propeller-heads) are talking about, so here are the three fundemental parts of JDF.
The job ticket is the most frequently discussed aspect of JDF. There are two “views” of the job contained within the JDF. The “Product” (aka “Product Intent”) and the “Process” view. The Product view provides a snapshot of the finished product from the perspective of an end-user or print buyer. It describes, for example, a 32-page A4 folded to an A5 saddlestitched brochure, black-only text on 100 gsm paper, with a four-color front and back cover on 150 gsm coated cardstock. At this level it takes no account of the size of press sheets or how the job will be imposed, trapped, etc.
As the name implies, the Process view contains specific settings, parameters and dimensions to allow the automatic setup and execution of a job on various machines. The step-by-step flow of a job through the plant is defined in great detail, even including the instructions to move the pallets or rolls of materials physically between production stages. Every action taken by each system or system operator is logged into the JDF, providing a time-stamped audit trail that allows for job analysis later.
How does the job get from one system to the next? Beware of instructions such as “The operator opens the JDF file,” or “The user drops the JDF into a hot folder.”
While technically it is feasible for employees to drop files containing little chunks of XML into a hot folder, doing so is counterproductive. The goal is automatic intersystem communication — you want to eliminate any direct user input.
The Job Messaging Format (JMF) is the means by which the data, expressed as JDF, actually moves from one system to another. JMF is a series of XML commands and queries. Again, because they are part of the standard, the sender and the receiver write and read the messages and understand the same thing. Examples range from the “SubmitQueueEntry” command, which inserts a job in the input queue of the receiving system, to the “Resource” query, which demands a report of the current state of a particular resource: paper, ink, employee, etc.
JMF uses HTTP or HTTPS as the transport protocol. Since the average IT person is familiar with them, it makes life a lot easier when you need permission to install these protocols on the corporate LAN or connect through a firewall.
To send a job to a platesetter, the user selects it from a drop-down menu in his or her favorite prepress application, and off it goes. The action is the same, regardless if the job is destined for the machine in the next room or on the next continent. The fact that JDF and JMF are created and routed through multiple systems is completely transparent to the user.
Note the JMF concept of signals: A management information system (MIS) or a production control system can register signals from the systems in the factory. Whenever a particular event occurs, such as a digital printer going offline because the paper tray is empty, the printer's JDF interface can send a signal informing the MIS or production control system of its status. Rather than relying on an operator to look for blinking beacon lights on the shop floor, the systems can send a help message proactively. Real-time job-costing data can be sent in the same manner, allowing the MIS to create a constantly updated financial picture of the job as it progresses.
The third aspect of the JDF standard is the packaging mechanism that allows everything needed for the job, or sub-job, to be bundled up and sent together. Again, the engineers are probably the only people who will care that packaging uses MIME encoding or that it is multipart/related.
But even the layperson might be interested to know that JDF references the various assets, such as PDF, ICC profiles, etc., using URLs just like those used on Web browsers. This allows the receiving software to know which files to use as inputs, how to name files and where to put any files it creates. When everything is grouped into one of these packages, that linkage must be retained. A multipart/related package must retain the relationship between the parts even while they are within the package, and once unpacked, those references still will come out making sense and the downstream software will be able to use those unpacked files appropriately.
Most people use MIME packaging every day without knowing it. Whenever you drag a JPEG file onto an e-mail and send it as an attachment, you actually are Base64 encoding the JPEG and embedding it into a MIME-encoded stream that is sent using SMTP to your mail server — and you don't lose any sleep over it. Similarly, MIME packaging of JDF will show up in graphic-arts applications as a check box with a name like “Package PDF Files.” The end-users don't need to know anything about the mechanics; they will use the software's features without needing to understand how those features work.
JDF is simply a tool. Using JDF as the glue between systems provides a means to reduce the cost and the risk associated with building smooth workflows. The ROI is in the value of the improved total workflow, not in a single machine's JDF-certified control software.
Don't restrict your JDF ROI by limiting the issue to prepress, press and bindery. Consider the entire supply chain. Think of the role you play as a point on a line between your customers' customers and your suppliers' suppliers. Such an integrated workflow can allow you to generate real data about your production process and make business decisions based on analysis of that data. A better link between you and your customers makes it easier for them to do business with you. If you can order the appropriate quantities of materials at the optimum time, you can reduce your costs.
Information technology is useless unless a company's management understands what is technically feasible and its IT staff understands the organization's goals and objectives. Even the most sophisticated information technology is a waste of money if it doesn't improve the company's ability to make money. Get training for your management on supply-chain concepts and how JDF can facilitate your company's role in that chain. Get training for your IT staff on the technical details of supply-chain management and JDF, and then ensure everyone understands the business plan. Ensure all staff — geeks and non-geeks — are making the best use of IT in pursuit of improved corporate performance.
Gareth O'Brien is CEO of Objective Advantage, a software business-development company. Contact him at firstname.lastname@example.org.
Alan Darling concedes that, as executive vice president of Vio (Roseland, NJ), he has a vested interest in the success of JDF. But, in an open letter to the industry this past May, the exec offered his opinion as “a user and proponent of standards.”
As we noted in October 2002's “Standard Update,” Darling joined Quality House of Graphics (Long Island City, NY) as COO and CTO in September 2001. He was responsible for developing an integrated technology strategy that encompassed Quality's ad-agency and printing clients and their internal workflows. From 1995 to 2001, Darling served as president and COO of Western Laser (Valencia, CA). Prior to that, he spent nine years with Quad/Graphics, Inc. (Sussex, WI). The exec worked for Monotype, both in the UK and the U.S., from 1974 to 1986.
Darling is a past chairman of the Digital Distribution of Advertising for Publications Assn. (DDAP) and a member of the Committee for Graphic Arts Technology Standards (CGATS).
An excerpt from Darling's letter follows.
What was shown at Drupa was a staggering array of solutions, and CIP4 sponsored an area in which interoperability could be seen in action.
In my 30 years in this industry I have never seen such cooperation. The companies involved in CIP4 are investing many hours into determining what should be done and then more hours in [making JDF] work.
After seeing or reading about the array of tools at Drupa, what [should] you do? Look at all the different processes you have in your company and identify one or two that could benefit from better management and more automation.
Here's an example. When I was running a shop, I had a client that spent an hour writing a job ticket which they faxed to us prior to submitting their digital files. Our CSR then needed another hour to key the information from the fax into our job ticketing system.
We created a method to generate the job ticket as the job was being created; data was automatically extracted from the file as it arrived and sucked into the ticketing system where the job tickets were created automatically. Not only did this save two hours, it allowed us to accept jobs 24/7. Jobs got into the system quicker, and we were actually able to reduce the client's pricing through efficiency.
This project was done before JDF was even a twinkle in the developers' eyes, but I would have used it in a heartbeat to normalize the job tickets coming into the shop.
The beauty of JDF is in its logical progression. I can now take the JDF metadata (the digital job ticket) that comes in with the job and feed that to a digital invoicing system to generate billing faster and more accurately. Do not underestimate the power of increased cash flow!
As more of your workflow becomes JDF-enabled, that initial JDF job ticket marks the start of a job's life, which can now be tracked through JDF as it moves through your shop.
JDF is the key to unlocking this industry — we have to be able to identify the locks into which this key can be inserted.
I am bullish on JDF, but only with your involvement. You, the user, need to get involved and identify processes like the one that I have described above and implement a 21st-century solution to address it. It really is common sense to use JDF. Work with your vendors and workflow partners to identify the areas that will initially benefit from this the most.
Contact Alan Darling at email@example.com.
AMERICAN PRINTER, in cooperation with NAPL and CIP4, has produced a three-part series on JDF covering process automation, the supply chain and real-world implementations. All three can be viewed at www.americanprinter.com.
“The Digital Dots Buyer's Guide to JDF” covers the JDF basics, including the role of management information systems and what major workflow vendors are doing. See www.digitaldots.org for ordering information.
Written by CIP4's Jim Harvey, “Process Automation” explains how JDF will impact graphic-arts production managers and IT professionals. It also features a checklist for establishing process-automation priorities. Download it free of charge at www.vio.com/whitepapers_index.html.