3 Reasons to Make the Move to JDF
The buzz around Job Definition Format (JDF) in print industry communication has been gaining momentum. This SolimarSecrets video provides valuable insights into why making the transition to JDF is worth considering. Here are three compelling reasons to embrace JDF:
1. Streamlined Cross-Vendor Workflow:
JDF is a technical standard developed by the graphic arts industry, serving as an external job ticket that offers precise processing instructions to workflow systems. It simplifies cross-vendor workflow implementations, ensuring seamless production of specific products, primarily using PDF print files. While various methods exist for communication with printers, JDF stands out as a standardized approach that supports critical features like page-level finishing, bi-directional communication, and detailed job processing information retrieval.
2. Enhanced Visibility and Control:
One of the standout features of JDF is its support for bi-directional communication between JDF-enabled devices via their (digital front-end (DFE) controller to the Solimar Print Director Enterprise (SPDE) and SOLitrack receiving messages back via Job Messaging Format (JMF). This communication allows real-time monitoring of job progress, error detection, and reporting of job completion. Operators can pause or cancel jobs without physically intervening on the shop floor. Such control and visibility are invaluable in minimizing blind spots within production workflows.
3. Accurate Job Costing:
JDF provides a standardized mechanism for retrieving information about the work performed at the printer and the ink or toner consumables used for each job. This feature is handy for tracking costs associated with specific jobs rather than general device operating costs. Although vendor support for this aspect of JDF is yet to be universal, it holds great potential for cost analysis and efficiency optimization in the print industry.
Although JDF still needs consistency across the industry, it remains a favored print protocol, especially for PDF documents. With the backing of both vendors and end-users, JDF is the dominant standard, unifying stakeholders around a single communication protocol. Moreover, the future of JDF looks promising with the emergence of JDF 2.0 or “XJDF,” a simpler and more standardized version designed to facilitate vendor support.
JDF offers significant advantages such as standardized cross-vendor workflows, real-time visibility and control, and accurate job costing. As the print industry continues to evolve, JDF’s dominance as a communication standard will likely grow, making it a worthwhile investment for businesses seeking streamlined and efficient print operations.
There’s a lot of buzz around JDF in the market these days. But do we really need another way to talk to printers? Today we’re going to talk about how JDF and JMF work, how Solimar supports them, and discuss the pros and cons of JDF over other methods. The job definition format, or JDF, is a technical standard developed by the graphic arts industry to facilitate cross-vendor workflow implementations. It is an external job ticket that provides processing instructions to workflow systems to facilitate production of a specific product using one or more print files, most commonly PDF.
Where JDF is a job ticket, JMF is a bi-directional communication protocol used to communicate from a JDF controller to a worker in the JDF system. It provides a common vocabulary that allows one device to communicate with and even control the other. In this case, the controller is SPDE or SOLitrack and the worker is a printer. This diagram shows the typical communication pattern used when submitting a JDF job to a printer. Using the JMF message, submit queue entry, a JDF job ticket and a PDF job are submitted. The printer then provides job status messages like 5% on 10% done until the job is complete. When the job is complete, the controller can request return queue entry to retrieve the JDF file from the printer. The return JDF contains extra information added to it by the printer about the job’s execution. Things like RIP time, potentially ink and media used for the job. SOLitrack will read the return JDF file and store ink and media usage with the job. More about that later.
There are a lot of ways to talk to printers. We’ve been doing it for over 30 years using various protocols and JDF is only one of them. The three main benefits of JDF are its support for page level finishing, bidirectional communication and the ability to retrieve information about how the job was processed at the printer. All of these things have been supported by different vendors in different ways for years. The difference is that JDF and JMF is a standard and it supports them all. In most print streams, finishing information applies to the entire file. For example, printing a document from Word to a local printer and having a corner stitch applied to the whole job. This is what most print streams were designed to do. What if you had a print stream with thousands of documents within it, each requiring things like stapling, multiple tray pulls, jogging of output? There are ways to do this today, but they’re all a little bit finicky. Proprietary job tickets work great, but only for one vendor and maybe only one of the devices for that vendor. PostScript can support this as well, but again, it’s hit or miss depending on the vendor and the device. PDF supports page level finishing through the standard DPM finishing that is part of the PDF. This is similar to an embedded job ticket. Sadly, it’s been ignored by print vendors. Good news is that JDF supports page level finishing. The bad news is that instead of the standard JDF way to do things, many of the vendors have wrapped their proprietary methods in JDF. As time goes on, vendors are embracing the standard approach. Hopefully a generic standard JDF will be all that we need. Until then, Solimar supports proprietary JDF flavors, as well as all of the other methods described here, and more.
Without bi-directional communication with your printers, you really don’t know what’s happening at the press. Did my job get there? Is it running yet? Are there problems? How much is printed? When will it be done? You can call the operators on the floor or have the operator manually mark a job completing your workflow system. But bidirectional communication closes the loop automatically, removing a major blind spot from your production workflow. You can see from SOLitrack or SPPD the status of your job on the printer in real time. You will know immediately if there are errors or warnings. You can see the percent complete. All of this is very useful. The printer can tell SOLitrack or SPPD when the job is completed so that it can automatically track completion time in the system and move the job to the next step in the workflow. Another benefit is that you have control over the print job as it is executing on the printer. You can do things like pause printing and cancel jobs without going out to the shop floor.
JDF has a standard mechanism for retrieving information about work performed at the printer and consumables used for the job. Vendors have addressed this in proprietary ways using software at the DFE or the printer itself. JDF does this at the job level. It tells you what was consumed for every job. This is very handy for tracking costs of specific jobs rather than overall cost to run the device. While JDF does provide a standard for this, vendor support is still spotty. Today, SOLitrack can request this information after printing a job and use it to populate ink and media usage for the job, if your printer vendor supports it. The hope is that in the future this will be more broadly supported by vendors and that more information will be available using this mechanism.
As you can see, JDF is nowhere near perfect, even after 23 years of trying. The bottom line is that PDF has become the dominant page description language and JDF/JMF is the preferred print protocol for PDF. While support is inconsistent across vendors, it looks like JDF may be dragged by PDF to become the winner. Right now, you can count on some basic capabilities with JDF, but I think these will continue to become more comprehensive and standardized over time. Other methods are what they are and will continue to be supported, but not really extended much. Right now, vendors and end users are investing in JDF and with no successor in sight, it looks like it might be the only show in town. For now, it seems like all stakeholders in the industry have finally coalesced around a single standard.
So, what does the future hold? JDF 2.0 or XJDF is the next evolution in the JDF standard? JDF 1.0 is extremely comprehensive and capable, but very complicated. JDF 2.0 is refreshing in that it is a simpler, more practical version of JDF designed to make it easier for vendors to support instead of trying to be everything to everybody. It focuses on practical, real world use cases, point to point communication in a workflow. No need to worry about compatibility. XJDF is 100% backward compatible with JDF for users. XJDF just means that it will be easier for vendors to support the standard in the future. JDF and JMF are not perfect, but they’re very capable and have some advantages over other methods.
JDF makes it easier for Solimar and other vendors to tightly integrate workflows. Standards like JDF really help everybody in the industry, making it easier. Having one dominant way of communicating with printers helps us all in the same way that PDF helps us all having one way, even if it is imperfect, is still better than having ten imperfect ways.
