3 Reasons to Make the Move to JDF

Hello. Welcome to our session about JDF and JMF and reasons why companies are moving towards JDF. There are several ways to drive partners, and the topic of JDF may come up with looking at how to drive your production printers with PDF workflows. This session will cover why JDF and JMF have become a popular method to drive printers, how they work, how Solimar more supports them, and the pros and cons of JDF versus other methods of communication with printers.

First, let’s start with a couple of definitions for JDF and JMF. The Job Definition Format, or JDF, is a technical standard developed by the Graphics Arts industry to facilitate cross vendor workflow implementations. It’s 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 or Job Messaging Format, is a bidirectional communication protocol used to communicate from a JDF controller to a worker in a JDF system. It provides a common vocabulary that allows one device to communicate and even control the other. For our context, the controller is our Print Director Enterprise or SOLitrack solution, and the worker is a printer. This diagram shows the typical communication pattern used when submitting the JDF job to a printer.

Using the JMF message Submit query entry, a JDF job ticket and PDF print job are submitted. The printer then provides job status messages like 5% done, 10% done until the job is complete. When the job is complete, the controller can request to return query entry to retrieve the JDF file from the printer. The returned JDF file contains extra information added to it by the printer about job execution, such as the report time and potentially ink and media used for the job. SOLitrack will read the returned data file and store the ink and media usage with the job, which we’ll expand on later. There are several methods to drive printers, and we have specialized in doing it for over 30 years using various protocols. JDF is just another one on the list and is gaining in popularity, while many others such as Novell, Parallel, SCSI, Bus/Tag, SCon and others fade away.

Three main benefits of why JDF is gaining market share 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, but one difference is that JDF, JMF is a standard and it supports them all.

With most print streams, the finishing information applies to the entire print file. For example, printing a document from Word to a local printer and having a corner stitch applied to the whole job, which is what most print streams are designed to do. However, what if you have a print stream with thousands of documents within it, each requiring things like stapling, multiple tray juggling, output, and more? There are ways to do this today, but they can be a little finicky. For example, proprietary job tickets work great, but only for one vendor. It may be only for one of the devices for that vendor. PostScript can support this as well, but again, it’s hit or miss depending upon the vendor and the device. PDF supports page level finishing through the standard DPM finishing, that’s part of the PDF spec, which is similar to an embedded job ticket, but unfortunately it’s been ignored by most print vendors. The good news is that JDF supports page level finishing in a standardized way. The bad news is that instead of the standard way of doing things, many vendors have wrapped their proprietary method into JDF if they supported it at all. As time goes on, vendors are embracing the standard approach and hopefully at some point, a generic standard JDF will be all that’s needed. Until then, Solimar supports proprietary JDF flavors for various vendors, as well as all of the other methods described here and more.

Without bidirectional communication with your printers, you really don’t know what’s happening at the press. Questions such as did my job get there? Is it running yet? Are there problems? How much is printed? When will it be done? May not be conveniently answered. You can call the operators on the floor or have the operator manually mark the job complete in your workflow system. But bidirectional communication closes this loop automatically, removing a major blind spot from your production workflow. With JDF, you can see from SOLitrack or SPDE the status of your job in the printer in real time. You will know immediately if there are errors or warnings, and you can see the percent complete, which can be very useful. The printer can tell SOLitrack or SPDE when the job is completed, so that we can automatically track completion time in the system. And for SOLitrack, 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. For example, you can do things like pausing, printing, and canceling jobs without having to be on the shop floor. This feature of JDF is pretty neat. 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 on the printer itself. JDF does it at the job level. It tells you what was consumed by every job, which is very handy for tracking costs for specific jobs, rather than the overall cost to run a device. While JDF does provide a standard for this vendor support is still pretty 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, more vendors will support this and that more information will be available through this method.

As you can see, JDF isn’t perfect, but the bottom line is that PDF has become the dominant page description language and JDF, JMF is the preferred protocol for PDF. While support is inconsistent across vendors, it looks like JDF adoption may be dragged on by PDF to become the winning protocol. You can currently count on some basic capabilities with JDF, but this should continue to become more comprehensive and standardized over time. Other methods to drive printers are what they are and will continue to be supported, but not really enhanced that much. Today’s trend is that vendors and end users are investing in JDF and with no successor in sight. So, it looks like the main protocol for consideration when the functionality it supports is needed. For now, it seems that many vendors in the industry are in agreement about using JDF as the predominant standard.

However, what does the future hold? JDF 2.0 or XJDF is the next evolution of the JDF standard. JDF 1.0 is extremely comprehensive and capable, but it’s very complicated. JDF 2.0 is refreshing since it’s 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, and a workflow. There’s no need to worry about compatibility, as 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, so it’s good for everybody.

At Solimar, we leverage JDF as part of our Chemistry platform’s output management with SOLitrack and SPDE. SOLitrack has robust support for JDF and JMF, allowing you to monitor the printer and job status, as well as enhance controls such as cancelling the jobs on printer from within SOLitrack. This helps to provide a centralized insight to keep users informed about what’s happening during printing activities, and generates alerts if problems arise. With JDF and JMF, after jobs have run, you can even retrieve ink and media usage for the job if the printer supports this. When driving printers, SOLitrack also supports JDF and JMF to support information exchange, such as finishing controls, along with the job and printer status.

Although these are intended to be industry standard protocols, not all vendors have implemented these the same way and may use proprietary syntax and commands. So, to help support the integration with various vendors, SOLitrack has additional options to specify how to control the printers and how device status updates are obtained. For example, controlling spot colors for HP Elite controllers, referencing processing to the end of the file on a RISO, the job timeout values for Fiery, and specifying what printer to root a job to when a single Canon controller is driving multiple printers. As PDF continues to become the dominant file format for printing, another key feature with JDF is at page level finishing, such as tray calls, jogging, and plex can be controlled when printing PDF files, versus having to convert your PDF files to PostScript or IPDS to control the finishing of cutsheet printers. This saves processing time and production, along with simplifying the workflow, and can reduce the overall cost of the solution. To control finishing with JDF, SOLitrack checks the finishing commands for each sheet and conditionally maps them to the appropriate JDF controls and method of communication for the printers.

Since controlling finishing with PDF files is one of the main reasons to implement JDF, it’s worth mentioning how you can add finishing information to your PDF files in the first place. In our Chemistry platform, our conversions to PDF will include the finishing information from the original input data into the output PDF file. If you’re starting with PDF or want to modify the existing finishing information, our Rubika solution’s finishing module can conditionally insert new finishing commands such as tray selection, plex, stapling, and binding information to the output. This is commonly used with PDF input files, where no finishing information is included in the files, such as outsourced PDF files you need to print, or controlling the plex and tray calls as needed. Rubika allows you to conditionally define finishing content when it doesn’t currently exist in the PDF file, and enables you to make changes to your existing finishing information within a PDF file.

For example, you may want to change the media color from blue to pink, or specify that the first page of each mailpiece is a simplex page to be printed on letterhead paper stock, and that each subsequent page should be printed on the duplex on plain paper. When the finishing is set to duplex, Rubika will automatically pad mailpieces to have odd page counts with the blank back side so that the next mailpiece starts on a new sheet. Customers have told us that this was difficult to do with other solutions, but with Rubika it supported automatically by simply setting the finish in the duplex. Rubika and Solimar’s overall Chemistry platform incorporate finishing information in the PDF files by using annotations or comments in the PDF. If the input is a print file, the existing finishing is included in the output as annotations that are associated with each sheet in the PDF file, but don’t actually appear on the page display space.

With the Chemistry platform, you can ingest almost every type of finished information, add, remove, or modify, and then output them to about any other method. This greatly simplifies moving work from one cutsheet device to another. Using Rebecca, you can also control finishing by adding barcodes to drive offline finishing processes. The PDF files can be converted to other formats that support finishing, such as PostScript, and when printing PDF files directly to the printers, the finishing commands can be controlled with our support for JDF and DPM Finishing with the PDF files natively. Just depends on what the printer supports.

And as mentioned, although there’s a JDF standard, different print vendors will use their own syntax to control the finishing. With their automated workflow, the ADF job ticket information can be customized for what each printer supports. And, if JMF is supported, we can register the printers feedback, such as ink and paper usage to use for reporting and costing. JDF and JMF are not perfect, but they’re very capable and have some advantages over their methods. JDF makes it easier for Solimar and other vendors to tightly integrate workflows and standards like JDF really help everybody in the industry by making various aspects of the workflow easier.

Having one dominant way of communicating with the printers helps us all, just like PDF has help with the document presentment. Having one standardized method, even if it’s imperfect, is still better than having to support several imperfect ways.

Thank you very much for your time. If you have any questions, we’re easy to reach and look forward from hearing from you.