PrintWeek recently published an article where they debated the effectiveness of JDF and its adoption within the industry. Our MD Keith McMurtrie was asked to contribute and gave his thoughts on the topic. Read his full answers below and then check out the link to the full article at the bottom of this page.
Why has JDF not achieved what it set out to do in terms of automation and integration?
"JDF set out to define a universal platform that would allow vendors to communicate with one another without having to write separate interfaces - to make use of the ‘Write Once Use Many’ principle. And that’s what it achieved. We may not be seeing the level of automation and integration that we expected in the sector, but I don’t believe we can blame the JDF standard for that.
The issue is the level of adoption from the vendors themselves. Whilst JDF has given them a base starting part to use to communicate with one another, each vendor has adopted it to varying degrees, and this makes collaborative working pretty difficult.
There are some areas of JDF that are better spec’d than others and I would suggest that the conventional printing specification is extremely robust and well supported by all vendors, whilst pre-press can be hugely complicated. And just as pre-press vendors themselves have different functionality between them, so must their interfaces. And we can’t really blame JDF for that.
I always explain the JDF standard to people as a huge book of ingredients, which is what came out first, and the interpretation of the recipes was left to the imagination of those vendors who adopted it. When the industry failed to come up with these recipes themselves, CIP4 created the Interoperability Conformance Specification (ICS), which was like a book of standard recipes, each with different levels of complexity.
If the JDF dream was in any way flawed, it was that it tried to go too far, too soon. By only providing that book of ingredients initially, it ended up becoming an all-encompassing standard for the theoretical scientific world rather than the real world."
"Those printers that have embraced JDF are using it extremely efficiently and don’t perceive it to have failings, but as the technological world of print develops, it’s not the only way forward. I like to think of JDF as being a multi-purpose tool that’s part of a bigger tool box that printers can use to connect their products. So whilst I might come across as a JDF purist, I see myself as more of a pragmatist and acknowledge that we have to use the best tools for the job."
"The future of JDF is an interesting one. Vendors like ourselves who have been involved from the early beginnings have invested a significant amount of time, effort and money into JDF workflows. And the knowledge of JDF is scarce enough as it is, so to embark on something new is commercially daunting.
The JDF schema is described as being XML but it’s actually XML with a twist because it has some non-standard XML characteristics that can make it a challenge to manipulate the JDF file with standard tools and technologies. But CIP4, under the leadership of Rainer Prosi, has recognised this and has been pushing the merits of XJDF (or JDF 2.0) for some time, with an official launch at Drupa this year. This version of JDF is pure XML and has taken a lot of the characteristics of the JDF 1.X whilst removing some of the duplicity and complexity. As much as everyone accepts that it makes technical sense, the challenge is for vendors in these difficult and challenging commercial times to commit more resource into supporting what is effectively a new format.
We hear a lot about APIs these days and whether these are the future. But, whilst an API does offer an easy way to communicate, it still requires each vendor to create a proprietary connection each time. For example, we have an API that allows anyone with programming competence to communicate and interact with our MIS, but the APIs for every other MIS vendor will be fundamentally different to ours, and the connections therefore couldn’t be used again.
HP’s PrintOS also uses an API and requires those that want to collaborate in this environment to write a specific interface for it. Whether this could ultimately be a replacement for JDF, I doubt very much.
Heidelberg’s Push to Stop technology is a concept and not a standard architecture like JDF. It’s taking advantage of capability that’s been on Heidelberg presses for some time and adding some improvements to the user experience in commissioning an operation.
JDF is more far-reaching than this. In fact, products such as Prinect from Heidelberg, Apogee from Agfa and XMF from Fuji are fundamentally based on JDF and use it internally as a means to communicate between its own systems. So to suggest that JDF has failed and should be replaced would be catastrophic to these suppliers."
You can read the full article here.