[Openicc] Linux printing

[Kurt Pfeifle]

Am Feb 28, 2012 um 07:52 AM schrieb Kai-Uwe Behrmann:

> Hello Michael,
> 
> Am 27.02.12, 21:52 -0800 schrieb Michael Vrhel:
>> It is not true that Ghostscript will assume DeviceRGB is sRGB.  Ghostscript can be specified to use specific ICC profiles for DeviceGray, DeviceRGB and DeviceCMYK.  In fact, Ghostscript can have different source ICC profiles specified for different graphic types (e.g. text, graphics and images in DeviceRGB and DeviceCMYK color spaces).   These can even override ICC profiles that are internally specified within the document.    Object dependent ICC profiles can also be specified for the output device ICC profile and DeviceN source color spaces can be specified with external ICC profiles.
>> 
>> Ghostscript can also include a proofing ICC profile and a devicelink ICC profile for the output device.  For example, in the case of the device link profile you could have a device profile that was Forgra 39 followed by a device link profile that mapped cmyk to cmyk or cmyk to rgb depending upon the final target device.   Similarly, for a proof profile, the color mappings will go through the backward and forward mappings of the proofing profile and then through the actual device profile.   This is obviously done in a linked manner though.
> 
> Great feature set.
> 
> We do not know, how to use these options, if desired, in a standard CUPS workflow. The PDF OutputIntent appears one of the few means to send a device ICC profile to Ghostscript. I currently see no means to utilise that for proofing, as a device link without PCS is pretty much out of question for the PDF OutputIntent. And setup of multiple per PDF object type profiles appears impossible with CUPS (or should I write out of scope).
> 
> It would need a custom pdftoraster filter to workaround this limitation. 



My first question here is this: how does the (current) pdftoraster Ghostscript filter (-sDEVICE=cups) handle/honor the embedded ICC profiles?

If this works well (enough), one could use the Ghostscript pdftopdf filter (-sDEVICE=pdfwrite) to apply/embed whatever profile I wanted/needed to the original PDF, no?

But having said that, my main doubt is somewhere else: what value/benefit lies in the retrospective enforcing/embedding of ICC profiles, if the original document didn't care about color management (CM) in the first place? 

AFAIU (and I'm a complete noob in all things concerning CM), CM does only make much sense if it is taken care of (AND if this is done correctly!) in each of the document workflow stages, from document creation through all intermediate steps/conversions to document output. You can't bolt CM onto ICC-bare documents and expect print results to improve much and consistently in a controlled, pre-defined way. 

ICC-experts, please shut me up if I'm wrong.

Note, I'm in favor of all efforts to add CM to Linux and Free Software and don't want to badmouth it. All I say is that we also need CM support at the application level before it can have any lasting and consistent effect on output quality.