Print Business explains why JDF is definitely the way to automate the print industry

www.printbusiness.co.uk

JDF is firmly back on the agenda as the need for automation increases and printers have to balance costs with shorter runs and faster turnarounds. And now there is a new version coming to making it easier to make the connections between production processes.

According to the information posted on the Cip4 website, Cambridge is “like Belgium, but more interesting” and that for the first JDF InterOps meeting in the UK which took place in the university city: “In April, it will rain”.

Other highlights for developers coming from MIS, press and prepress vendors to test their technology, included a trip to the Cambridge computer museum.

This prompted late night discussions about the archeology of computer languages, storage media and communication protocols.

As yet there is no section in the museum dedicated to JDF, the Job Definition Format, the glue that holds the printing industry together, nor probably a reference to the protocol in any of the print museums around the globe.

For the moment JDF is still evolving. It was first described in a darkened conference room below the Moscone centre in San Francisco during a Seybold Conference in 2000. The Seybold Conference has since disappeared, but JDF rolls on.

Its four original supporters have been joined by 150 more companies from across the printing industry pledged to the cause of integration of technology to pass production data from one divide to another. JDF predates Industry 4.0 and the Internet of Things, but its heart and its brain are in the same place. It is all about automation and connecting different devices.

The InterOps meeting, sponsored in the UK by Imprint MIS, provides space to test those connections. A spokesman from Imprint Business Systems says that the company had looked at supporting a meeting in London, but was put off by the cost.

The academic surrounds of a Cambridge college on the other hand were close to Imprint’s home near Chelmsford and proved ideal for a meeting of computer software engineers.

Developers armed with laptops and simulation software were able to run tests to check the integrity of a first time connection between those present. This is exactly what Imprint was doing, checking and testing communications with Agfa in Cambridge rather than at the customer site.

This is a key reason for attending the InterOps meetings. The major companies always have implementations to check, and increasingly complex connections as automation begins to take a grip. This would be possible on a bespoke, customer by customer basis, but having JDF as a standard creates the handshake protocol to simplify the entire process and make it less painful for printers.

Stephan Richter, Heidelberg, explains: “My role is to work with third party MIS suppliers on a huge number of MIS integration projects. We will consult with the customers to understand their needs and goals.” With the developers lined up behind screens in a room off the East Staircase in Fountains Court at Clare College, communication between them is as easy as conversation.

Discussions can take place using all the latest digital communication tools, but face to face works better, says Cip4 chief executive Henny van Esch. “Having this meeting is better than any webinar,” he says. “That we also go to interesting places helps.”

“The InterOps meetings are the place to check to test the newest versions of the JDF standard and those that are still in development,” Richter continues.

“When we do, it means fewer surprises when you get on site at a printer. It is very important for Heidelberg that we have JDF as a standard format. Standardisation helps with automatisation of the industry, controlling how to get a job in and how to produce them.

“With each project, we learn something new and customers benefit from the experience we have built up over the years.”

Agfa’s Koen Van de Poel agrees. He is also chairman of the CIP4 prepress work group as well as leading R&D in that area for his employer. The company was testing the passage of information about a job, the intent in JDF speak, to an Imprint MIS. The lessons learned at college will be shortly go live at the customer’s site. The lessons learned will also be captured and docu- mented to the later benefit of all.

Each vendor has its own flavour of JDF, says Van de Poel. “We have completed the work on the core of JDF,” he says. “It is now about customer specific tasks.” The code that is created to enable these can either become part of the hefty JDF standard if there are going to be more customers wanting this extra functionality, or left as an evolutionary dead end if it is likely to be a one-off.

JDF has become mature. And it has grown up in a fast changing world. When conceived digital printing was a minority pursuit and wide format printing almost unheard of. These technologies have had to be included in the original work.

It has not been a story of JDF sweeping all before it. In the continuous feed world, other standards applied and are still in use. It is also noticeable that the Japanese digital press vendors have been slower to endorse JDF than the German litho press suppliers.

As JDF has developed, so the world around has changed. The internet has expanded exponentially to the extent that the Internet of Things is more than a concept and Industry 4.0 has emerged to encompass the ideas of automation and communication that lie at the heart of JDF.

But the tools used today to create and read computer languages to extract the data they contain, have also changed considerably. When JDF was conceived it chose one flavour of XML. Now that has become somewhat cumbersome as the nature of the JDF job ticket has been to carry all the data about a job from beginning to end of its journey.

In an ideal world this is not a big problem, but very little print about is ideal. Customers will always want to change the numbers printed in a run, perhaps to change the paper used or even to switch from stitched production to perfect binding. In JDF this meant going back to the start and describing a new job.

“Changing the job details in JDF was very, very poor,” says van Esch. The answer to the conundrum and others is an new JDF, one that Cip4 is calling XJDF. This was under discussion in the second half of the week in Cambridge and having earned the support of all, is quickly moving to the point where it will start appearing in future workflow products.

The aim is to bring JDF up to date from a technology viewpoint so that it becomes part of the Industry 4.0 movement. “JDF was defined before the Internet of Things,” says Richter. “It had the same goal as Industry 4.0 in promoting the close integration of different systems and JDF is crucial to that.”

The form of JDF and the schemas used by XML to provide the structure for data carried have also evolved. XJDF is intended to bring this up to date. It will eliminate the chance of ambiguities in how the XML is set out and will enable developers to use readily available tools to create and to parse an XJDF schema.

Most importantly perhaps, the job ticket no longer has to stagger around under the weight of data that is irrelevant to the current task. The location of data about a job will be set rather than allowing different vendors to structure job descriptions as they like.

In the new format, only the relevant subset of information is sent to each device on the production journey. “It becomes much easier to handle alterations, says van Esch. “It will be easier to parse the files, easier to read using standard XML developer tools: savvy printers will be able to create their own scripts. But other printers will notice almost nothing.”

There will be a period when the two forms of the standard run alongside each other and those businesses that have strong JDF integration tools are unlikely to rejoice that they will need to repeat the process for son of JDF.

“This will make it easier for newbies to implement,” says Tharstern CEO Keith McMurtrie. “But it will also make some implementations more complex as support for the new version will vary.”

In short XJDF data will not automatically run in existing JDF systems, nor vice versa as the new version imposes structure on where, as well as how, jobs are to be described. It will take time for the new interfaces to be rolled out while some will use JDF to XJDF translation tools at least for an interim period.

The smoothness of an integration will depend on the quality of this transition. And this perpetuates the problems that have been identified with JDF.

The rapid increase in short run jobs and demanding production schedules has increased the requirement for automation. For the first time German online print giant FlyerAlarm was at the meeting in Cambridge. “It handles 15,000 jobs a day. How can it do that without automation?” says van Esch.

As a new business, it plans to leap straight to adoption of XJDF. One aspect of XJDF is that it handles job ganging, the ability to impose multiple jobs to a sheet and to extract and assign costs to each.

Web to print implementations ought to become easier as the amount of data needed at the time of ordering print will be more limited and files from those systems that support XJDF will flow more easily into a hands off production workflow, Agfa’s Apogee for example.

Once there, other production parameters will be added to create the file that can accompany the artwork through production steps. And this feeds back information to the production hub, the MIS and perhaps to a customer wanting to track job progress.

This still relies on JMF, the Job Messaging Format. “We have customers who are only using JMF to deliver information can to the MIS to improve estimates and costing by showing ink consumption, times to make ready and run for example,” says van Esch.

In turn this improves scheduling by delivering real time information to the planning system. There is no point in allocating a job to a particular press when plates have not been processed because the customer has still to sign off the file.

This is where JDF has stuck to the original concept. In the subterranean room in San Francisco where many first heard about the format, they were told that the system would work out that a stitching line could be start up half-an-hour after printing the final section had begun, even though the press was still running and the last section would need to be folded because presses run faster than finishing lines.

By overlapping production processes, there would be no gaps for waiting and therefore production efficiency would be improved over the print and wait production methods then universal. It of course made no provision for standing time for the job to dry. But the presentation was evangelical, so persuasive that such practical objections could be swept aside. At least until later.

And at the time few printers could even contemplate either needing to deliver work the same day, nor that the volume of job handled per shift would leap as it has. This has made automation essential and continues to drive the uptake of JDF.

“We have noticed a rise in the number of requests for information about JDF and automation in recent months,” says Richter. “There is a lot of potential out there.”

Heidelberg thinks of a customer implementation in three phases. The first is the quick win, linking prepress to press which is an everyday occurrence and the benefit ts understood. Even so each project begins with a workshop setting out was is expected from all sides and creating the objectives and measures to judge if the project is a success.

A three-day workshop follows and each project will last about 6-9 months. “This Level 1 implementation gives the customer the confidence that the approach can work and it means they are ready for the next project,” says Richter. “It is a key success factor in adoption of JDF because it always works. And this gives the users confidence that JDF works, they get to see the benefits of automation and feedback so that they get hungry for more.”

Van de Poel warns that full company-wide buy in is essential as without full support at all levels, the project will fail. “We have to check that there is full support and commitment from management because that management support is needed. We have learned over the years how to spot a project that will work and which will not and are much more selective today about which we will pursue.”

The typical AGFA project will involve job submission onto the prepress workflow resulting in a hands off plate production process. The software is perfectly capable of coping with the production steps needed and to ensure that originators have submitted files correctly and that these are processed with the correct colour profiles and screening for the chosen output.

Many printers, he says, have been reluctant to strip out the prepress department in favour of account handlers approving plate production after receiving full customer sign off.

These customers are also responsible for the failure of many JDF projects as files need to be clean before entering the prepress workflow, giving rise to “JDF stands for Just Don’t Function” comments. Printers need to insist that files are submitted to the specification provided and that those that do not match must be rejected. “It is a cultural rather than technical problem,” Van de Poel says.

AGFA is now starting to prepare for demand from wide format printing where the urge to automate has not been as strong. “It is a very different environment,” he continues. “Not many are even aware of JDF. But Agfa is using JDF internally to communicate from a storefront into the Asanti workflow and into our new wide format printers.”

Allowing non compliant files into the network is responsible for 80% of problems encountered, says McMurtrie, the solution being the preflighting gatekeeper where the onus is on the customer to ensure they have produced a PDF in the approved print ready way.

The advent of XJDF should make this easier as file structures will be the same and all job tickets have to be set out in the same way. But inevitably there will be a lag as some components of a workflow will be compliant with the new version, others will remain JDF compliant. “A lot of time and resource has already been spent on creating JDF interfaces,” says McMurtrie, “and in these difficult and challenging commercial times, it will be a challenge for vendors to commit even more.”

This raises the possibility of two- speed automation as the leading companies adopt XJDF while those that cannot afford to commit the resources lag behind or use another interface to convert the incoming XJDF into the existing JDF that they know how to work with. “Any type of conversion or translation brings a risk,” he says.

The risks, however, are that without the change JDF will become too cumbersome to work effectively. Already some companies have built their own XML to XML interfaces, either as suppliers or as print businesses. The range of tools that XJDF developers will exploit is also available to IT staff able to create the necessary scripts. Few want a return to complexities that this will introduce. XJDF is the way to go.

The format is now with members of Cip4 for comment and suggestions before the geeks gather again in Dresden in September where KBA, celebrating 200 years in business in 2017, will be the host.

The plan is for full ratification by then. The dates being suggested for this meeting note when school holidays are scheduled and that on 19 September it is international talk like a pirate day.

For more information call 01245 231670 or email [email protected]