Debugging Color... (cont.)

(Continued from the PDF Outsider because the same issues apply here...)

So once there is a problem it has to be sorted out.

Many times the source of the problem is hard to identify.  For example, proofs are always produced with a new customer is taken on and the customer sees something and approves it.  It turns out to be quite difficult to manage color in that context if equipment and workflow is changing.  Remember there might be a dozen steps along the way in the process.  Each step involves its own version of software and hardware.  Since these jobs run over time (months or years) various elements get upgraded and changed along the way - perhaps by another silo in the organization unrelated to production.  We call this "configuration creep".

Configuration creep is significant problem in large companies with multiple print devices and multiple plants and debugging color relative to it can be challenging because it may not be possible to "go back" to the approval configuration.  For example, a conversion element is upgraded and some new default converts color to RGB instead of CMYK - either intentionally or inadvertently.

Configuration creep is the nightmare of any production manager because its totally out of his control yet it can completely stop production.  Debugging this problem is horrific because you have to trace back and determine what, if anything, might have changed.

Another debugging area is what we call "content creep".

Content creep is process by which elements of a large, complex production jobs change over time.  This is particularly important in workflows that involve cached assets, i.e., VDP workflows with PPML or AFP.  In this context assets of various sorts are used in jobs but are not organized as part of the job.  What I mean by this in AFP you can reference external job elements that are not part of the per job per se.  In the print job there is a reference to element - typically cached in the printer - rather than the actual element.  There are analogous scenarios for PDF (PPML).

So as long the elements don't change everything works.  But what happens when a logo referenced in dozens of jobs changes?  For example, I am holding output from a job and it contains the new logo.  Is this particular job supposed to use the new logo?  Large workflows generally try and control content creep with elaborate asset management processes.  But these are only as good as the people who use them and quite often mistakes are made along the way.  Sometimes the shop floor personnel don't know that the asset should change and report problems that are not problems at all.

Another interesting debugging issue follows along these lines:  A customer calls and says that there is "ghosting" around small type on some specific jobs.  After much anguish it is determined that what's happening is that on some parts of the job around 6pt type the device is not registering colors accurately and CMYK black is causing a problem.  So here you have to debug the hardware first and determine if its working correctly.  Given that it is you next have to figure out how the CMYK black got into the workflow.  Since jobs come and go over the course of a year you may discover that someone working on the job last year created a bad asset.  Of course CMYK is not allowed but that doesn't mean people don't find creative ways to inject it into the workflow.

You have to look for everything from a new asset sent by a customer that bypassed checking (somebody was in a hurry to get the new asset into production and just assumed it was correct) to a personnel change and someone forgot to follow the standard asset management steps.

Next post we will cover data driven color problems...