Nobody knows when the first ‘JDF is dead’ article was written, probably shortly after the specification for interconnectivity in the printing industry was first described 20 years ago. And there have been many since. The Job Definition Format is an idea whose time is coming, has come, or has already vanished.
The truth of course is more nuanced and more complex. What people, like printers, took to be the promise of JDF – that it would connect any piece of production equipment to any other and that a job would flow seamlessly from file received to job delivered using whatever production path was deemed most appropriate – has not been delivered. Implementations have been long, hard and expensive. And for many, have produced huge benefits. Many of the online print companies have built their business around end to end automation with JDF as the exchange format.
Some of the JDF implementations are enormously sophisticated, though most are more straightforward, linking prepress to a litho press and sending information back to a MIS system about what has happened, rather like a railway signalman showing that the line is now clear. The problem is that JDF has perhaps fulfilled its promise to suppliers – of retaining control over their own technology, while paying lip service to the idea of connectivity.
In this case, connectivity comes with a price, often one that is so off putting that many printers decide not to proceed, or else, choose to stay within the walled garden that the supplier has made around his own technology. Few printers have the IT skills needed to map the processes involved in their factory, then understanding where the opportunities for automation exist, assessing the value of these and then implementing a solution.
The perfect example of the supplier led approach has been Heidelberg. With Prinect it can go from prepress, involving a Signastation and Suprasetter, to one of its Speedmaster presses and then on to a guillotine, folder or perhaps a stitching line or perfect binder. The only thing is that now Muller Martini owns the saddle stitching and binding technology and would rather these sat within its Connex workflow system.
Heidelberg was among the founders of JDF, creating Cip4 as the natural successor to Cip3. This was a data interchange between prepress and press to deliver ink duct setting information culled from the imposed PDF, so reducing makeready times on press. A fourth P was added to indicate that post press and production information was now included. However, the cost of making the integration has been a huge barrier, particularly in finishing.
The argument used to run that as printers replaced old machines, the newer ones would be JDF ready or JDF compliant. The cost of the interface could be part of the investment, not tacked on afterwards. It has not turned out like that. Printers install new equipment alongside old and seem to want compatibility across everything. The lowest common denominator approach means there has been no overwhelming desire to implement JDF in finishing.
The cost of an implementation has been a major impediment. The concept was sold that once a connection had been established between manufacturers, subsequent implementations would be fast and easy. It has not really worked out like that.
The Cip4 organisation that oversees the JDF standard meets at least twice a year for interops testing, in which the developers from one company share desk space with software writers from another to accelerate an implementation project and test connectivity between systems.
Successful projects are listed on a matrix on the Cip4.org website to indicate that the connection has been established and that it is working in the field somewhere. This is great for MIS to press or prepress, less so if it is MIS to prepress to digital and litho press to web to print, to folder, to guillotine and to binder. Each interface needs to be tested and tweaked in turn.
Part of the problem here is that the JDF tries to tell the receiving equipment how to do a job, not just what the outcome should be. Maintaining the JDF specification and possibilities under these circumstances is a Sisyphean task. The JDF specification weighs in at almost 900 pages. With the organisation preparing to launch JDF1.7, further paragraphs can be expected.
It also makes assumptions that the specification of the job will not change. It is not easy to make changes on a live job, say if the customer wants to add pages, or the B1 press becomes unavailable. It is frequently easier to start again.
Cip4 knows that there is a problem with JDF. A couple of years ago, it released a cut down, simplified version known as XJDF. This would overcome some of the meandering that exists in the main specification where the standard has had to be adapted to cope with phraseology or technologies that were not considered when the standard was drawn up.
This has included some post printing techniques that were not considered at that time. It also considers the way that terminology in litho printing and digital printing differ: perfecting or duplexing for example.
XJDF was introduced in 2018 “to simplify workflow automation by making it both easier to implement and far easier to validate using standard XML tools.”
Because XJDF is designed as a pure information interchange interface, it is not full digital job description but a means of describing the intent of the job ticket to the device receiving that instruction set. “This reduction in complexity should lead to faster, simpler and more robust integration of devices and applications in the graphic arts.”
Two years after publication of the first version, there are no publicised implementations or case studies from Cip4 to show the success of the new format. This specification is also hefty, weighing in at more than 450 pages including appendices, 360pp without. Now XJDF 2.1 is on the point of publication, filling a few gaps that were left from the first release. And while XJDF uses some industry standard tools that were not available when JDF was first drawn up, it is still very much the son of JDF.
Despite this, Cip4 has been the only realistic game in town. Some digital print sites have been able to implement automation helped by the limitations created by the two-page format, or else in continuous feed inkjet by the sorts of products that are described. Others have created workarounds to bridge gaps in the main specification.
Kodak has done some of these with its Prinergy workflow to link to MIS providers, like Dataline in Belgium or Tharstern in the UK and US. “If we bring something to Tharstern, they are very quick to implement it in their system,” says Peter Hulsmans , VP workflow sales at Kodak Europe.
Prinergy is based on a Rules Based Automation concept, where a job flows through gateways, changing direction according to choices: paper type A or B; run lengths to switch between litho and digital and infinitely more. Close collaboration is needed between Workflow, MIS and press vendor, using JDF. The installation at ESP in Swindon is a showcase for JDF with Tharstern, Kodak and Heidelberg all integrated.
“We work closely with Komori,” he says, “getting the feedback that we need. And a company like Tharstern is not tied to a press vendor. Now we are trying to do more with XML and APIs.”
This is opens up to a world of data flows from, say, Oracle enterprise management systems to modern CRM systems like Salesforce. Prinergy can provide the analytics back to the MIS for costing and comparison to the original estimate. “It allows Tharstern to produce more accurate costings by stating how much ink has been used: you can’t do that with JDF.”
As inkjet printing takes hold, accurate costing of ink consumption becomes essential to ensure a profit rather than a loss. This is a gap that may be filled in a future version of JDF, but it will not happen rapidly because it will need thorough testing.
This requirement is a weakness of Cip4. The format reflects the industry in the years leading up to the turn of the millennium. It was one of the first standards for automation to be launched in any industry. Subsequent industries have adopted a more modern XML.
That first vision of a JDF linked printer was described during a presentation at the Seybold Conference in San Francisco in 1999. The job would move from prepress to press and into finishing, at all times communicating its status back to the central system which could then assign the resources needed for production. There would be no need to finish one step before considering starting the next step; the system would do this automatically.
So when the press was only part way through printing a job, a folder could start up scheduled so that as the last stack of printed sheets was finished in the press delivery it could be taken to the folder while previously folded sections were being loaded into the binding line. The presentation seemed blissfully unaware of the need for sheets to stand before finishing.
Likewise real production experience seems lacking in some of the forums where refinements to JDF are discussed. Specifying the “first fold on the long edge is clearly not a good idea, for example.” Conservatism also comes though these conversations. Despite the growing pressures, these are dismissed as “the epic JDF in the Cloud”.
And new formats for communication and data exchange have faults. One comment states: “Although JSON has little additional merit compared to XML, we can’t keep our eyes closed and ignore JSON. We definitely either want XJDF to be ignored (too old school, not JSON) nor do we want variant dialects.”
That is certainly what Zaikio intends and has done so since before acquisition by Heidelberg. Christian Weyer is the computer neuroscientist who spotted the scope for a better structure to underpin data exchange in the industry. It needed to be based around a semantic description of printed products, breaking a book or a catalogue into its component parts and so enabling automation to be applied to these.
Speaking after Crispy Mountain was acquired by Heidelberg 12 months ago, Weyer said: “Over the last couple of years we realised that print companies in different areas are very simple. Commercial printers are similar to other commercial printers, but book and commercial printers are nothing alike.
“We want to help creative people around the world to get their ideas on paper: we want to get the process out of the way. This is not just for the printer, but also for publishers and in that way we are moving away from the Heidelberg area because end to end is the only way we can make this work.
“Software in the printing industry is cumbersome and doesn’t talk to each other so in order to automate you have to spend hundreds of thousands. That simply is not feasible any longer.”
Before its acquisition by Heidelberg, Crispy Mountain had developed Keyline, an MIS which underpinned an automated workflow at Latvian book printer Livonia. Livonia has integrated presses from Canon and Heidelberg, and has Muller Martini finishing. This led to a portal that allows publishers to submit titles, place orders, and track the production of these orders. The printer is able to schedule a mass of jobs in an orderly fashion. “It has helped us discover how to build an automated digital print production line in the first instance with offset following.
“The company gets all the information it needs to take the book through imposition, printing, folding and binding. The only way to do this is with good semantic data. The challenge is to be able to extract information from the publishers who will frequently have 20-year-old computer technology, in a meaningful way. We have to show that there are benefits. The publisher gets a streamlined process. The printer uses Keyline to automate procurement of paper, to handle production and scheduling and deliver a price back to the publisher in a couple of seconds, without reference to static price lists,” says Weyer.
“It will give a price whether it’s for ten books or 50,000. This has previously needed separate processes and it is completely transparent to the user who doesn’t know what equipment will be used.”
There are other implementations of Keyline around Europe. That software is now largely absorbed into Heidelberg, along with data feeding imposition, so that this is fully automated with no need for an operator.
The user interface is also deliberately modern, far faster and more intuitive than other industry software. “We are very proud that the user interface is simplistic,” says Weyer. “The magic is happening behind the curtain.”
The intention had been to launch the integration platform at Drupa, initially known as HeiOS. Now without Drupa, the announcement has been made, the name changed to Zaikio and the concept of using servers in the Cloud to link one application to another without the pain of having to write an interface. The system will make use of APIs to link to outside service providers, inventory management and delivery, for example.
The element that does this is called Mission Control, where the connection between one application and another is made while linked to the Zaikio user account to record the traffic and which applications have been used to that purpose. Weyer's semantic structure is crucial to ensure that all available apps are communicating in the same language while the JSON format allows those descriptions to grow and shift as necessary through the production process. At the outset the publisher is specifying a book, not assigning a specific folder to the job. This decision is made automatically at the point it needs to be made.
The developers that want their apps included use APIs to link on application to another using the Zaikio structures. This includes applications well away from the printing industry proper.
One of the first demonstrations of how Zaikio will work is planned with procurement technology. It is being put through the development process with a small number of printers and paper suppliers. The first beta tests begin in the next few weeks with the aim of a full release before the end of the year.
By making ordering paper (and other consumables) digital, resources at both ends can be freed up and, because the amount of information the application can sift, better decisions can be made. Previous attempts to make paper purchasing digital have been too clunky to catch on.
“We are working with other MIS and with substrate providers,” says Karl çiz, partnership manager. Like Weyer, çiz came from a computing rather than a print background, his being in e-commerce. This resulted in a spell with UnitedPrint, until spotting the opportunity that Crispy Mountain represented. Online print specification as the start of an automated workflow is a clear opportunity.
It is also one where Zaikio will run into Enfocus, the closest model to Zaikio that currently exists. The Switch workflow tool is a connector that has allowed companies to build on boarding workflows to take in jobs via web portals, generate proofs for online sign off and then proceeding to imposition and generation of a Cip3 or JDF file for the press. Switch has no real interest in going beyond the prepress element of the workflow.
Siteflow does go beyond the press, in this case an HP Indigo. It was developed as a way to automate management of job of one printing, a photobook, calendar or greetings card, for example. It has been acquired by HP to be a cornerstone of that company’s PrintOS environment, where, like Switch, an app store approach allows customers to access tools or workflows that are proven to work within that eco system. When Heidelberg first bought Crispy Mountain, it seemed that its concept of a platform for the industry would be a similar platform for Heidelberg users.
Heidelberg is now at pains to stress that this is not the case. It is the owner of Zaikio, but is looking for other investors to join in to validate its belief that this is something that the industry needs. With a more than 40% market share, Heidelberg does not need to drive press sales Weyer points out.
PDF perhaps provides a guide. The format was created by Adobe as a means of containing the sprawling monster that PostScript had become and to take the format away from purely print. The US software giant has since handed PDF to the ISO to become a true standard.
There is a long journey ahead for Zaikio before its format reaches this point. The company’s roadmap follows beta testing of the procurement platform with beta testing of the core Mission Control module. By the end of this year the first products are expected to be available in the Zaikio app store. These will include apps for job routing and to link to check out software on third party market places. Zaikio will be able to provide an online purchasing, printing and sales environment.
In the early part of next year further apps will become available including its own Keyline technology for accounting, production planning and scheduling as well as for imposition and preflighting. “The ultimate goal is to democratise the whole industry,” says çiz. “JDF has not done this. The core focus of establishing a working relationship printer to printer, product to product, is not so simple to execute. Then with the introduction of XJDF there was a hope that this could be a step forward. Instead what has happened is that people have found ways outside of JDF to side step the problems of JDF.”
“What will make or break this will be the number of developers that sign up,” says Weyer. “Though at the end of the day the customer decides what they like better.”
The ultimate idea will be to access direct data from presses and other machinery. If this is not possible, tablet data entry is possible, again designed to capture information in just a couple of clicks. “What we need from the machine is process information, what the job is, how many good copies, how much waste. This is not a difficult task in computing terms, and provides information that allows dynamic production planning,” he adds.
That is a parallel need to the Push to Stop technology that Heidelberg has on its presses and the similar tools that others have developed to minimise makereadies. In a perfect world every job arrives when it should, passes swiftly through preflighting and reaches the press at the same time as other jobs sharing the same type of paper, keeping to the schedule mapped out at that morning’s production meeting. Unlike trains though, print jobs rarely run to time.
And the prediction is for more and more shorter run print jobs coming down the line. Zaikio’s task is to make these trains run to time.
Automated workflows are going to be increasingly necessary to cope with an increased frequency of jobs. Printers will not be able to add staff to cope, and consequently, automated workflows reducing manual touchpoints, are essential. A first demonstration is likely to take place at the open house planned for the PMA in Wisloch in October.
Story 1 of 2