JDF: The Key to Successful Print Shop Automation

Hey, I’m Pat McGrew with McGrewGroup, and I am with one of my favorite people. Drew Sprague from Solimar Systems. And we like to get together, Drew, to talk about weird technical topics from time to time. And the one I really want to investigate with you today is JDF, because you’ve been around like I have been through a lot of the standards development, a lot of the CIP4 meetings and PDF meetings and had all sorts of interesting conversations with people over the years. But, we’re sitting here in 2023 and it feels like JDF has finally become an adult and we’re all ready to sit down at the bar together and have some great conversation and actually do some business together. And. JDF It seems to be a full member in that conversation. Now, I think a lot of the reason that JDF has become so interesting is because of all the talk around automation and at its soul, Solimar is an automation company. So how do I win in automation, with JDF?

Well, hi, Pat, Nice to see you again. Thanks so much for bringing up this topic. You know, what we’ve found is that the model that users want when they print is not just to send it and forget it. They want to know what’s going on. And, the more they automate and the more they integrate complex systems, the more they need to have that dynamic feedback. And so fortunately, JDF is a big player in that communication link between host systems and device. And as you know, a PDF has really taken the forefront the lead in the data stream of choice for driving devices. And because of some of the things PDF doesn’t natively have, like some of the other data streams in that finishing capability, JDF is a natural fill in for that too.

So, if I’m in a PDF workflow environment, and I know that I have to do more automation, I know that I have to be smarter about how jobs come into my shop and I have to be smarter about what I know about what’s going on in my shop, what’s going on on the presses, what’s going on in all these different places. Can JDF help me do that? And what’s the mechanism in JDF that lets me know what’s going on and exchange information?

Well, fundamentally, JDF is basically a job ticket. But it’s more than that. It’s not just here’s what I want you to do. It’s a container where the information can actually get updated by the device or devices in the system. And, so JDF plays a really important role because it becomes kind of a document of record of the things going on in the workflow to finish that particular product, which doesn’t have to be just a single document. It can be a more complex fulfillment application.

So, JDF can talk to all the finishing equipment as well as the printing equipment and the workflow solutions set.

That’s the design of the concept behind JDF is that it’s not just for print, it’s really for a production floor. In fact, it wouldn’t even have to necessarily have print at all. But yeah.

So, if I am a Solimar customer am I using JDF maybe and not knowing it?

Well, typically you would ask us to configure a system for you that contains JDF because there are a lot of different options because there are a lot of different printers with a lot of different DFEs and what any one particular company uses is probably more specific to the kinds of workflows they have. For example, if you’re a company that traditionally has done a lot of AFP work, you probably have IPDS printers and wouldn’t use JDF typically in those workflows unless you start integrating a lot of PDF into your workflows. And then probably, yes, you would.

So, what makes JDF magic? What can I do with JDF that I can’t do by just writing a bunch of scripts?

Well, the basis of JDF is basically XML and the world has become very comfortable with working with XML because you can easily handle it in a in a programing coding kind of environment. Beyond that, though, JDF allows a lot of complex elements of a document production environment to be encoded into a single container. And, so the reason you want it is because you might not want to specify just what needs to be done on the front end as far as the printer handling it. And maybe setting certain pages to duplex and other ones to be pulled from the letterhead tray. You might also want to be able to specify that covers are going to be produced on a device and that’s a finishing device down the road is then going to assemble a book from that and maybe even stitch some covers together.

So, you refer to it as a job ticket. So, within my JDF file, I know what the requirements are, what the specifications are, and then does that file get updated as each task is performed during the job production?

Well, that’s right. That the intent is that the device doing the work is going to report back what it has actually done so that, you know, if the work actually got done and then that information can of course, be fed back into other parts of the system that need to, for example, bill users who are on the system. Oh. Or keep track of the flow of work because usually people are staging lots of jobs at one time ready to be performed as equipment becomes available. And, so having that dynamic feedback of what’s gotten done, what hasn’t gotten done is a really important part of making those systems flow.

So, can JDF talk to my press and tell a dashboard what’s going on on the press in real time so that we’re not constantly going over and looking at the DFE?

Yeah, well that’s certainly the intent is that information flow goes first to the device. Hey, here’s what I want you to do. And then as the work is getting done, it’s a dynamic update of information so that the dashboard can in real time present what’s actually happening at the device with the particular job. Right.

So, I guess I’m starting to get the sense that JDF become sort of the Star Trek Universal Translator and it’s able to talk to all the devices and all the processes and then share that data as appropriate with all the other processes that need to know about it.

Yeah, certainly that’s the intent. But I think at the same time, there’s also an intent that people will progress because the CIP4 people have put out the XJDF model. That brings us a little closer to true XML and a little simpler model for how to move this thing forward into the future so that more people adopt it and use it.

So, I’m so glad you brought up XJDF because I keep hearing you use the word intent. There was this intent that JDF would do, you know, a laundry list of things. But in practical reality, we’ve noticed that a lot of people only use tiny pieces of JDF capabilities because it’s what they’ve been able to figure out or it’s what they’ve been able to implement. So, what does XJDF bring to the table that changes the story for us?

Well, it simplifies the problem. And in order to get systems, complex systems to be implemented, they can’t be so cumbersome that legacy alternatives can keep them sidelined. And, kind of what’s happened with JDF over the years is that it’s been kept sidelined by alternatives that may not be particularly elegant but are simple enough that they can be substituted. But, as time has marched on and people want more automation, the gaps left by those alternatives have been exposed. And that’s why JDF is gaining traction. And yet, obviously JDF has already been, from a spec perspective, obsoleted by XJDF. And, so it’s a natural progression that as organizations develop and then refine those implementations, that they will move forward from JDF to XJDF.

So, as we make that transition as an industry from sort of the big tent JDF thing to something like XJDF or to the XJDF standard, do I have to rewrite my whole workflow in order to take advantage of what I can do with XJDF?

Well, the intent is that you won’t have to, but I guess something not well implemented, you could end up with something like that. But, the way we approach various data streams and connectivity paths is that you can mix and match in a well-designed output management architecture having different kinds of interfaces to different kinds of devices, because nobody just swaps out all of their equipment at one time for the latest greatest new thing, right? So, in a Solimar environment, you might have people driving IPDS devices and some devices that are just traditional LPR kinds of connectivity or IPP or JDF or XJDF, because companies obviously, once they make a big capital investment, they don’t want to just throw that out just because there’s a new interface available, right? So, you kind of build things slowly and deprecate the stuff as you no longer needed.

Wow, hat clarifies a lot of things for me because I wasn’t quite sure if it was possible for them to live happily together, right? That JDF and XJDF could sort of grow up together. So, talk with me about how JDF really helps solve some problems. Some of the things we’ve talked with Solimar customers about over the last few years is their challenges in finishing and their challenges in controlling their process communication and their challenges in just understanding their own environment. And, I think I understand that if you’ve executed an environment where JDF and JMF the messaging format, are working in harmony with the rest of your processes, that it should be a better situation. But, I know that especially around finishing, I still talk to customers who have challenges because they grew up with PostScript. Maybe they don’t turn things to PDF until the very last minute. They were used to putting a lot of finishing commands in their PostScript. PDF didn’t really make that easy. So, does JDF have a role in helping fix that situation?

Well, it does. As the world is migrating to PDF, the gap that PDF has left is the finishing model that supported in the PDF specification has not been widely adopted or not sufficiently widely adopted for the number of people that want to use PDF to print. And, so fortunately for JDF, it has been more widely implemented and it’s readily available from a lot of vendors currently. So, when you have a PDF file and you want to finish it in particular on a cutsheet machine with tray pulls and stapling and all that kind of stuff, you need a nice clean way of presenting that information to the DFE, the front end for the printer so it understands what you want to do. And absent proprietary job tickets, which once you get switched to a new printer vendor, that job ticket workflow you set up may no longer work. JDF, being basically a vendor neutral format, allows you to set up a workflow that will work for you no matter what you integrate into your environment.

So, I was used to document part metadata as something that we should be striving for. And does JDF replace that?

They’re very similar in structure, but yes, JDF can be used in place of DPM, as we refer to it, those little nits and gnats that can go inside of a PDF file and tell you how you want to finish it. The challenge with DPM is that a number of DFE vendors have just found it too complicated to implement when they see a clearer path to implementing JDF and getting that adopted. Because, in addition to the DFEs having to be implemented, then you have to have most software that implements DPM and a lot of organizations have not done that. So, although we’re a bit unusual in that we support DPM and JDF and a bunch of other things, that’s not universally true. And, so when you have a workflow that may for example, want to consider using PDF in a cutsheet environment that has all these complex finishing workflows needed, you know, different trays, tray pulls and mixed plex and stapling and offsetting, all that kind of stuff. JDF has a very natural path to move forward with that because the structure is well-defined and it’s straightforward for the DFE vendors to implement that.

This is about to get much more important in the industry. I think we’ve both seen the survey work that’s been done that shows cutsheet inkjet is going to grow, it’s going to, dare I say, explode over the next few years as more and more equipment comes to market. And, if you were doing continuous form, maybe you didn’t worry so much about things like sets and offsetting and stuff because it wasn’t part of your finishing solution. But, if you are a cutsheet shop, this is pretty important to you to be able to do it. So, as we’re going forward, it would seem that a lot more people will be interested in all the things you can do in a JDF for finishing environment.

Yes, certainly. Of course, that cutsheet lends very well to short run work and so that’s a reason that that people would want cutsheet as well. It’s the ability to get feedback from the device. What’s happened, not just, hey, did I get the data and did I process the job, but how much colorant did I need for the job and how many sheets of paper did I use. That kind of stuff that can all come back at the end of the job from the device through the JDF and be reported back to your systems that do your accounting or manage your inventory, that kind of thing.

So, using JDF, I can not only capture all this information, but I can, instead of holding it on a DFE where nobody can get a hold of it, I can actually share it out to integrated MIS or my ERP or my inventory management system to let it know how many sheets I actually used. I can actually have conversation or my software can actually have conversations and keep things up to date.

Well, that’s right. And it goes even beyond that because the device can report back status information about itself broadly, that’s not necessarily job specific and that can all come back in the JDF file, for example, it can say, hey, you know, somebody left the paper or the door opened for the door on the machine open for some period of time. And that can all be collected and fed into a database for service purposes.

Wow, and I guess it should give you more of a heads up about required maintenance. I guess it forms the basis of a really powerful way to run your print shop.

That’s right. And that information can, if vendors want it to be device manufacturers can be very specific to their device.

So, let’s talk a little bit about what all that JDF based automation really looks like, because I know Solimar is a workflow automation company. You have customers who do some amazing automation. They actually do a really great job of trying to understand all the different things that are going on in their shop and get them as automated and streamlined as possible. Because I think all of us are working in a world where it’s harder to find qualified staff, it’s harder to get people trained. So. the more we can automate the processes, the better we are. Solimar has some customers that have done some really cool things. And, I guess the first question I want to ask you is why does the Solimar environment? Why does the Chemistry platform make it easy for Solimar customers to enable automation of these complex processes?

Well, Pat, when we set out many years ago to get into this industry, what we quickly found was that it kept changing and we couldn’t settle on being one thing and be happy because the target was changing. And, so actually a cornerstone of our success has been being a small company in a rapidly changing space. It’s kind of like being a tugboat in a small harbor versus being an aircraft carrier like we have here in San Diego. It’s much better to be a small, smaller sized thing when there are lots of changes because you can adapt so much more effectively and efficiently. And, over the years that we’ve been around, there have been a lot of changes in terms of the kind of content that people want to process. We started out working predominantly with AS400 and then PCL and eventually PostScript became popular and so on and so forth. And, now PDF and JDF are the thing. So, the Chemistry platform maintains all these things we’ve built over the years and allows people to leverage their legacy equipment, but to grow into new opportunities, more efficient ways of processing things without having to get rid of stuff before its time is due.

And, I know Solimar as an automation enabler for multichannel environments. So, out to eDelivery and all of the things that entails as well as out to print. But I’m constantly amazed at the new people who come to the Solimar platform. So, one of the customers I was told about is working with greeting cards and they’re not only using the platform to match greeting cards to envelopes, but also working with some other integration to match it to gifts that are going to go out with the greeting cards. Is the fact that you’ve got that JDF/JMF conversation capability what makes it attractive to a customer to use you as the basis of their integration?

Well, I think it’s more than even just being attractive. It’s there’s a certain level of viability, feasibility for certain workflows. You have to have the right ingredients or it just will not work. And, so JDF is a great tool to have to be able to facilitate complex workflows. It was really built with that intent so that people could put together very complicated but well-managed automated workflows. And, so that’s why we’ve thrown our hat into the JDF and XJDF workflow world.

And, I hear more and more commercial printers and not just, you know, traditional transaction printers that we know and love, but direct mail printers and commercial printers who do things like these greeting cards, talking about JDF and XJDF and trying to build automations based on the capabilities that it brings. Does that mean that going forward as you are traveling the JDF and XJDF path that it’s likely that you’ll be creating more tools that will be part of that XJDF toolkit?

Certainly, the easier that we can make it for people to use JDF in their specific environment because frankly, there’s a lot of variation in use cases among data sets broadly. And, so what one organization wants to do, somebody else may want to do something similar, but not exactly alike. And, so we’ll always be adding little inflections. For example, I spoke about pulling back information from the device. Well, certainly there are vendors out there that have not yet implemented JDF that will want to but will have their own special something they want to do that hasn’t been revealed yet.

Is this kind of environment one that makes it easier for an organization that wants to host multiple kinds of devices? We grew up in an era when you were either IBM or Xerox, those were your choices. You went one way or the other, and if you were offset, you were kind of Heidelberg or you were, you know, Manroland, And, so today in an average print shop that I walk into, they might have a Ricoh, a Canon, a HP, you know, some Komori offsets, a Mitsubishi offset. They’ve got a Heidelberg sitting in the back. They’ve got some wide format stuff that they bought from EFI. They might have some of everything. And can this environment work when there are so many different kinds of output devices?

Absolutely. JDF is a very flexible platform for being able to homogenize workflows. People that have legacy, for example, of working with IPDS content can easily within the Chemistry suite, transform that into PDF and then through JDF, feed that out to a device that speaks only PDF and JDF, and they may want to do so because there may be particular workflow requirements for a document that necessitates something that a that a particular device can provide that is novel to their business, broadly. They may want to, for example, target a more select group of their clients with a particular kind of document and be able to do so, but only with a particular kind of printer and thus that kind of integration ending with PDF and JDF makes it very straightforward to do.

Drew, what is your best advice to an organization that is trying to figure out their path forward with automation? They’ve got in the back of their head that standards are a good thing. Well, how did they take a practical approach to moving into an automated world with JDF?

Right. Well, of course they need to make sure that the device is supported and so they may not have the devices that currently support that so but pretty much everybody with print devices swaps them out every few years because they’re usually leased because they’re capital items. And, so as part of that planning for the next time they roll in a new device, evaluate what DFEs can I get for the device of my choice? And could JDF be an option or the primary interface to that device? Yes, that’s the first thing that I would recommend is, you know, kind of evaluate where you are in your capital expenditure cycle and make sure you’re planning for the functionality you need looking forward as opposed to just what you have right now in terms of the kind of workflows you can support.

We like to say do a self-assessment and figure out what you really have and then use that to have a smarter conversation with the vendors who are trying to sell you things.

Right, Right. And, it’s obviously going to be some combination of increasingly electronic digital workflows with some element of print and having that JDF/PDF element makes all of that easier.

Excellent. Drew, thank you. You have answered my questions about practical JDF and practical implementations. I want to thank you so much for your time. Oh, Pat, it’s always fun. Thank you so much.