[Openicc] [Gimp-print-devel] [Printing-architecture] Colour

[Chris Murphy]

On Nov 16, 2009, at 6:14 AM, Graeme Gill wrote:
>> Following  Chris' explanation, a print system "correctly" supporting 
>> Device(RGB/CMYK/GRAY/N) in PDF/X-3 will have a path to pass all colour 
>> management conversions unaltered. Could this become a simple means of 
>> implementing Mike Sweets less is more scheme of hiding CM controls? It 
>> would mean generate according targets and send them through CPD as file 
>> to the selected printer.
> 
> The problem is that for historical reasons, many applications print
> to Device(RGB/CMYK/GRAY) and expect reasonable looking output. For
> this reason many RIPs assign default profiles to these spaces,
> and in fact PostScript 3 actually has flags within the language
> to do this (I can't remember off hand if the same applies to PDF).
> 
> So to truly get device space, you need some other flag beyond
> using Device(RGB/CMYK/GRAY).

Not in a PDF/X context. By definition, DeviceRGB(CMYK/Gray/N) is defined by OutputIntent color space. Anything that correctly adheres to PDF/X cannot supply a default color space for device color other than the OutputIntent. At least in PDF/X there isn't another flag beyond using one Device color mode (same as the color mode of the OutputIntent), nor does there need to be for things that understand PDF/X.

But I'm not sure what the print spool file is on Linux. PDF/X-3 was suggested as a model for Apple to follow because they were already using PDF print spool files.

DeviceRGB/CMYK/Gray/N in the context I'm referring to it, is in the print spool file, and is a message to the pdftops or pdftoraster filters, to do no further color management on such tagged objects. It's a common convention in PDF/X. What needs to be done to get the RIP downstream to not do further color management is very device specific and how to put the printer in that mode, or form it's PostScript is something that needs to be in its PPD.

It is true that many PostScript devices have default color spaces, for instance laser printers will have an RGB CSA in them, responsible for converting any RGB content to CMYK using a CRD. The CSAs and CRDs can be in the printer or in the PPD.

The PPD for PostScript printers should contain the necessary information to put the printer into a "Raw" or "None" mode for color correction in the printer itself. If color management is occurring in the system, this path to the printer would always be used, and the system would supply normalized data.

The grand vision behind PDF and PostScript color management is that multiple objects in PDF tagged with multiple ICC profiles have their ICC profiles converted to PostScript CSAs when PDF is turned into PostScript. The destination profile is turned into a set of CRDs (one for each rendering intent used) and all of this is included in the PostScript stream sent to the printer. The printer's RIP then performs color space conversions of each object. This can work, but it is very RIP/printer specific. Some printers always ignore CMYK CSAs. Some printers always use an RGB CSA. So it's not possible to rely on the same behavior with every printer. It's likely best to normalize the print stream to a single output specific space, and set the "no color management" flag as a device specific flag (again defined in the PPD).



Chris Murphy