Heric says JDF is the real deal, but needs serious thought before implementation.
Had an interesting conversation with a couple of different clients recently… and both asked me a similar question, along the lines of… “What is this JDF thing?” They are both prepress operators/planners in a printery, but they both showed a curiosity in those three letters that had recently been added to the featureset of their new systems and desktop applications.“Is it like a PDF file or something?” one of them asked me. Neither of them knew that I have been involved with the most recent iterations of JDF (1.4), they just expressed a curiosity about this ill-documented feature that had been “just riding along” with their updated equipment. I had encountered this lack of awareness of JDF a few years ago, but I just chalked it up to its relatively new emergence into the industry. The fact that workers who should know what it was about, did not, caused me to think about why. Did they not need it?
Is there some reason they have not implemented it? Do they not have enough pieces in the puzzle complete? Curious minds wanted to know!
I explained to them that they can learn all about JDF at the website at www.CIP4.org. I continued with the brief description of what JDF does, and how it can be used in their facilities. These guys were excited. “You mean I can make my MIS system populate a JDF Ticket and use JDF to automatically pass the pertinent job information to the later stages in production?”
“That is what it is designed to do!”
I replied. To a man, they had wondered why they had not heard about it. I too wondered why the vendors had not made a more poignant mention of this entry into workflow automation.
Frequent readers of my column may remember one or two of my contributions regarding JDF becoming ubiquitous in the industry five years ago. The reality however is that adoption of this technology has been a bit slow due to the nature that people have tried to make their existing solutions work as long as possible, riding their ROI to the maximum. Adoption of JDF into ones workflow requires multiple stages in the process to be JDF capable, and that takes time for many of the small to mid-sized shops to implement in more than one or two stages of their workflow, and even longer to be able to implement into a complete “CSR/Estimation to production to delivery/billing” solution.
What does this say to me? It says that the vendors of the equipment used in the printing industry perhaps do not know precisely where to market JDF capability in their products, or how to make JDF compatibility a key-feature in purchasing new hardware or software solutions. To the guy in the trenches, or the workflow engineer at a printing facility, JDF is a godsend; to the guy signing the cheques, it is just another set of initials on the brochures, until it is implemented. It also says to me that it has been a long time in coming because of the simple fact that people do not intend to replace their solutions until there is a compelling advantage to do so. They did not make the purchasing decision based upon its JDF support, but were delighted to see that their new toys had this capability built in.
Obviously, the high-volume, large printeries have been aware of JDF for a long time, but a large number of small facilities are just becoming aware that the whole “process automation and standardisation” world that is JDF, is growing. Process automation, which has enjoyed the realm of the large commercial web conglomerates until recently, is on the minds of the workflow technicians at the smaller facilities. The difference now being that vendors are beginning to implement JDF solutions into lower end digital devices and software applications, by default. Many users are finding themselves JDF enabled, without even knowing it.In actuality, even under ideal circumstances, implementation of a JDF workflow is a non-trivial task. True complete JDF workflows still require a great deal of configuration, and a lot of coordination with vendor support, testing, and tweaking.
As these tools have been incorporated at a base-level in recent vendor solutions, their integration into workflows however is not only attainable, but absolutely worth the effort.
JDF is still not for everyone. Many modern workflows are trending more towards micro-workflows, where a digital printing device is fed directly from a desktop application, and finished/stitched brochures are the result at the end. In many new/modern applications, this is done with a JDF enabled device, but many times, it is done in a hodgepodge amalgam of colour laser copiers, hardware rips, imposition and planning applications, and workarounds that do not lend themselves to true JDF workflows.
Keeping in mind that the nature of JDF is that it is an interoperability format, and it takes multiple stages of the workflow to be JDF enabled before one can reap the benefits of workflow automation with it. It takes two to tango, and it takes a party to make a workflow run automatically.
CIP4 will be publishing JDF 1.4 at or near the drupa timeframe this year, and there should be more information available about it as that date draws near.
I can say from firsthand experience that the hard work that is undertaken by the CIP4 organisation is the result of many vendors with the altruistic approach of cooperation, and compatibility in a world of diverse, and disparaging workflows. The engineers responsible for it's development are indeed thinking about how print production can better be performed,
and how it can be streamlined in the future. If you see those JDF initials mentioned in your vendor's new available solutions, give them a look. Perhaps there is a workflow automation benefit in it for you.
