Cip4 has published the specification for a new communication protocol, XJDF, which it says will enable faster, cheaper and more versatile process automation than the original JDF standard.
This will continue to be developed alongside the new version, but once implementations of JDF get underway the expectation is that this will quickly become the choice for companies starting out on an automation journey. However not every piece of equipment and software will support XJDF at the outset, so the existing JDF format will continue to be developed.
Version 1.6 has recently been launched with the intention of supporting a parallel development path with the upcoming protocol. A key element in V1.6 is the plan to build a matrix of existing integrations so that engineers can avoid reinventing the wheel by repeating the pairing of different products. For the printer this promises a faster, and perhaps less expensive, implementation.
The attention however, must be on XJDF. Cip4, the organisation that controls both versions of print’s automation standard, says the new version is “designed to simplify workflow automation by making it both easier to implement and far easier to validate using standard XML tools.”
It does this by focusing on a ‘need to know’ principle. In conventional JDF, the entire workflow needed to be defined in the job ticket. This has made it difficult to cope with changes, led to inconsistency in describing the same terms and meant that comprehensive implementations can be drawn out and complex.
Rainer Prosi, Heidelberg’s Cip4 senior software architect who is technical officer for Cip4, says that this approach “provides too much information for devices such as printing presses, platesetters to finishing devices that do not require that much data to execute their activities and return status information.”
The XJDF format in contrast only delivers the data needed for the next production step. This will immediately make it easier to implement changes to the job, increasing or decreasing numbers printed, adding or removing pages, adding varnishes or changing a specification.
The support for XML editing tools brings JDF closer to the open standards world which was not possible at the birth of JDF when XML was also in its relative infancy. This support will allow home grown implementations of XJDF and much simpler interfaces between equipment.
The development has been welcomed by MIS suppliers. “We get all the benefits that XJDF offers from a technical perspective which makes it quicker and easier for us to support,” says Tharstern managing director Keith McMurtrie. “This in turn benefits our customers with more robust interfaces and predictable behaviour between different products.”
The hope is that the more straightforward approach will change perceptions of JDF and open it to a new audience. According to Prosi JDF has been associated with complexity, an academic approach, lengthy implementations and so only for larger companies.
This is a result of its origins at the end of the last century. Cip3 existed as a means to pass set up data, from prepress to a press with a digital colour profile to start to automate press set up, and from the press to a guillotine or folder. The big change was to build onto this the ability to feed data from an MIS and to send messages back to the MIS using the Job Messaging Format.
When it was drawn up, the world was dominated by litho printing and it was for litho printers. The developers also settled on formats that while highly flexible, allowed too much freedom to developers to create their own versions within the standard. Some tasks, making changes to the original job ticket, became cumbersome and troublesome.
XJDF aims to tackle this. It imposes a standard way to describe each step of a job. It enables changes to numbers and specifications to a job in progress because only the next step of the progress is described in detail and the use of more established XML formats will make it easier to connect outside applications to the print workflow, say electronic ordering, delivery companies and web to print.
Consequently, XJDF will also have appeal to online printers and those managing multiple jobs on a sheet. JDF was never designed to cope with this, leading to messy work arounds for those wishing to stay in a JDF environment. XJDF in contrast will permit dynamic changes, open the way to plug and play interfaces, reducing confusion and making the implementation much faster.
This is ably demonstrated in the published specification. The volume containing the full JDF specification runs to more than 1,000 pages. That for the XJDF amounts to 440pp. The specifications will not be exclusive: a JDF workflow will connect to XJDF and visa versa.
But the new version points the way towards an automated future. Prosi says: “XJDF offers an ideal means of facilitating communication among web to print, MIS, production and other systems to simplify workflow automation.”
Cip4 members have now got the task of implementing the new protocol. Some will do so quickly. Others will wait and see what printers require. In any case, XJDF will not be widespread until perhaps, Drupa in two years. When it arrives, printers need no longer fear the cost or complexity of automation.
XJDF promises to make the task of integrating different pieces of equipment and process steps in the production flow, not by trying to capture every detail before the job starts, but by delivering only relevant information to the next node on the production flow.