When it comes to standards and file formats designed for print automation, none are more useful than JDF. We spoke to Dr Rainer Prosi, Chief Technical Officer of CIP4, to find out more.
In our earlier article looking at the utility of XML, we saw that a particular print-specific version of XML was JDF (Job Definition Format). Created in the late 1990s by Adobe, Agfa, Heidelberg and MAN Roland, JDF is now managed by the International Cooperation for the Integration of Processes in Prepress, Press and Postpress (CIP4), a not-for-profit organisation whose aim is to foster the adoption of automation in print.
CIP4’s expressed aim of promoting open-source technology has the potential to cause conflict for Dr Rainer Prosi. Not only is he Chief Technical Officer at CIP4, but he is also Senior Workflow Architect at industrial print giant Heidelberg. However, he is clear where his personal preferences lie. “Personally, I would like more integration. And as I’m responsible for the integration of the Heidelberg Prinect system, I make sure that it is as open as possible,” Rainer says.
Open-source job ticket
At the root of CIP4’s mission and that dedication to open-source automation technology is JDF.
“JDF is the idea of a digital job ticket. In the same way as you’d have a paper job ticket that you’d send around a print shop along with the pallets saying, print this many, fold them this way, and so on, JDF describes all the kinds of processes in the printing world that a product will undergo. It also describes the connection of the processes, such as which one comes first. Of course, you must do the plate setting before you can print, and you have to print before you can fold,” Rainer says.
You can have a snapshot of your production at any given time without the entire job ticket coming back
“JDF understands there are dependencies – if the plates are not there, you can’t fold yet – so there is a model of resources and of processes. Typical resources are such things as the plates or the print paper, which we call components, and they can have all kinds of properties which is where print knowledge comes in.”
A question of information
The most obvious situation where a printer will begin encountering JDFs is in the use of a management information system (MIS).
“You need to have something that actually writes the JDF that does the planning for you and which prepares the automation,” Rainer says.
“A printing firm is not going to write that code by themselves unless it’s a large online printing firm which might have optimised its own workflow. But in general, a printing firm will either buy an MIS or a workflow system. The difference between the two is blurry: an MIS also deals with the financial side of things, whereas a workflow system looks more at the technical view of the processing.
“Typically, an MIS has an idea of what job it is going to produce. It knows that the customer wants it next Thursday, they want 5,000 copies at this size and here’s the PDF of it – that’s the information that an MIS has. Then it has to somehow think, here’s the product, now how are we going to produce this? Depending on that, you will have different workflows. You will either say: OK, if it’s just 50 copies I’ll put it through my HP or Indigo, but if it’s 1,000 I’ll put it through my Heidelberg.”
Once the MIS has the production processes decided, it can write the JDF.
“But the MIS also needs to know which devices are available and which other jobs are around – we can’t print everything at the same time, we have to sequence them,” Rainer says.
“These systems will communicate to the individual devices – the folding machines, the presses and the plate setters – using JDF. The system will then use JMF – Job Messaging Format – to report on the status of the process. If the JDF is the big job ticket, then the JMF is the message being sent back confirming that a stage in the process has been done. The JMF might say 10 copies have now been printed, or 20 are being printed every 15 seconds, so you can have a snapshot of your production at any given time without the entire job ticket coming back.”
To work with JDF and JMF, machinery and production processes need to satisfy some specific conditions though.
“There are two things to consider,” Rainer says. “You definitely need some kind of computer controller – if you take an old letterpress, it’s not going to work with JDF obviously. But what you can do in the case of old devices is to create what we might call a proxy controller in front of it, which is basically just a screen – an Apple iPad or whatever – and that displays to the operator what he or she is supposed to do. So, then the connection between the JDF and the machine is actually a human pressing buttons.
With XJDF, you know exactly where in the XML you write the amount, or the customer’s name, or the thickness of the substrate
“The next issue, especially if you’re talking about a financially focused MIS, is that sometimes it doesn’t get the exact details of the technology right. It has the information it needs to calculate the price, but it might not know exactly where the colour bars are on your sheet or what the exact thickness of the substrate is – it knows that it cost £2 a kilo, for example, but it doesn’t know that it is exactly 127μm thick.
“That flow of information using JDF is actually a fairly large issue. JDF allows you to define many details of your print job, but in general the device manufacturers would love specific, detailed information. Unfortunately, the people who set up the job don’t always have that information, so you end up having to live with fuzzy or lacking information.”
Streamlining the system
This propensity for JDF to convey a lot of information, but not always a lot of relevant information, has led to CIP4 rethinking – and rebranding – the format to become the more streamlined XJDF, or Exchange Job Definition Format.
“JDF was released in the early 2000s, now 20 years ago. That’s when automation started or what we call ‘Print 4.0’ was already in our minds, but a long time before people were talking about smart factories. That is one of the big issues with JDF. As the printing industry is not necessarily the most technologically-driven forerunner, a lot of devices weren’t ready and also the mentality just wasn’t ready for full automation at that point,” Rainer says.
“One thing with JDF is that we tried to define the process network really explicitly to say: here’s the plate making; the plates come out; the press consumes them, etc. To do that we needed to make a fairly complex XML structure, which the uninitiated had difficulty generating and consuming.
We took a step back and thought: what can we simplify? One thing was to take out the explicit definition of the process network and make it more implied because, by doing that, you could greatly simplify the XML structure
“We took a step back and thought: what can we simplify? One thing was to take out the explicit definition of the process network and make it more implied because, by doing that, you could greatly simplify the XML structure. Things like having to make the plates first before you can print are not encoded explicitly in the XML anymore, but there is an assumption that you know what you’re doing. Only the most important factors are in the XJDF.”
This simplified approach has another benefit, too. “It also means that you can use standard XML tools much more easily. If you look at XML, there are things like code generators based on XML schema, or XML schema that check the validity of your XML. All of that was very, very difficult with JDF; it could be done but it was clumsy. With XJDF it is a lot simpler.”
The reception to XJDF has been largely very positive.
“Whenever we have new projects at Heidelberg, especially with mid-sized printing firms that have small software developments, they are very eager to use XJDF rather than JDF because they can get a hold of it and we can write a specification much more easily,” Rainer says.
“With XJDF, you know exactly where in the XML you write the amount, or the customer’s name, or the thickness of the substrate. Because JDF was so flexible, it was confusing, but XJDF makes everything far clearer.”
XJDF isn’t the end of the print automation story. Read this article to see how PrintTalk, JSON and REST APIs can take automation even further.
by FESPA Staff