JDF: Helping Turnaround
A column by Stephen Beals
Just yesterday, our little print shop in upstate New York set a new personal-best record. Although I'm generally supposed to knock off at 4 pm, I made the mistake of still being at my desk at five minutes after the hour. That's when I found out that a job we had not yet received had to be delivered the following morning.
The job was a pocket folder to accompany the local university president on a trip to China. The university had used our company's FTP site before, so the customer already had a username and password. Within a few minutes, the necessary InDesign and Illustrator files were posted, along with the necessary fonts for the job (both parties having access to T-1 connections), and I had them on our server moments later.
One font did not survive the trip, but did survive being e-mailed after a quick followup phone call. All of the files were checked and verified by 4:15. RIP'ing a pocket folder took less than a minute"?much less time than it took me to properly impose the pockets, which the designer was not able to do herself. Few files, even those from our most knowledgeable designers (like this one), arrive completely ready for output, which probably makes us a lot like everyone else in this business.
By 4:30, we had a low-res HP proof ready to be trimmed down to the specifications for a standard pocket-folder die with business- card slits, and the high-resolution image was already coming off our EpsonStylus Pro 10000. But the customer need to see the finished product for an approval. In this case, a 150-dpi PDF file was not only easy and fast to create, but it provided high enough resolution for the designer to approve. Since it came in at well under 1 MB, it was also small enough to e-mail.
At 4:45, we had customer approval on a job that we hadn't known was coming in the door 45 min. before. The customerservice department had yet to write up the job ticket.
Today, this kind of turnaround may still be the exception, but it's hardly extraordinary. It is, however, more than a little scary. As turnaround times are compressed to the point of virtually disappearing, the need for corresponding job-monitoring capabilities increases. There is no time for proofreading or double-checking content or color. The designer who created the job is also approving it with no cross-checking. The job is in the system ready to run before we even know if we have the paper in stock to run the job.
The digital age, Internet, and e-mail have all made it possible to get a job from completion of the creative process to "ready-to-run" in less than an hour. But many print providers do not have the infrastructure to handle that kind of workflow on the front end.
This is part of the reason you will hear a lot about JDF (Job Definition Format) over the next few years, and there will be a compelling need to implement it in digital workflows. What must be done, and what we are unable to do right now, is that data must flow with the job"?from job entry to final delivery. JDF is simply a way of storing and reading data, and comparing and cross-checking it with other data throughout the print provider's database. It is a way of enabling us to tie all the bits of information about every aspect of a job together.
If the pocket-folder job described above took place in a fully JDFcompliant workflow, things would have transpired a bit differently.
When the designer completed her preparation work, she would dial into the printer's site and enter the job specifications and desired delivery date. The system would then query the database to see if the paper, ink, and press time were available to meet those specs. If everything was verified, the system would then alert the designer to send the files.
The system would alert the prepress technician when the files became available, and the JDF calls already in the system would carry the job specifications to the imposition system. The operators still might have to go through old-fashioned cutting and pasting of the file to make it work; but then again, if the proper template already exists, the system just might be able to handle it automatically.
The finished job would be sent to the appropriate RIP and the appropriate proofing devices, make the correct-resolution PDF, and e-mail it back to the designer for approval. JDF calls could even tell the die-cutting operator which die to use, and set up the programmable cutter to make the proper cuts. If you use a wide-format printer with cutting capabilities, there would be no need to set up the printer"?the JDF calls could take care of it automatically.
Slowly but surely
Perhaps that sounds like a system far off in the future, but such systems already do exist, and they will be making their way slowly but surely into all kinds of print shops. Of course, the human element will never completely go away. All of the information must be correctly entered in the first place. And the question of responsibility for errors will always start arguments, no matter how many safeguards are put into place. And, of course, suppose I had left the building at 4 pm, like I was supposed to?
Stephen Beals (firstname.lastname@example.org) has been in prepress production for more than 30 years and is currently the digital prepress manager with Finger Lakes Press in Auburn, NY.