User login

JDF: Helping Turnaround

(February 2005) posted on Mon Feb 07, 2005

A column by Stephen Beals


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 (bpworkflow@verizon.net) has been in prepress
production for more than 30 years and is currently the digital
prepress manager with Finger Lakes Press in Auburn, NY.


Terms:

Did you enjoy this article? Click here to subscribe to the magazine.