[Openicc] Linux printing

[Kai-Uwe Behrmann]

Am 28.02.12, 18:43 +0100 schrieb Kurt Pfeifle:
> Am Feb 28, 2012 um 07:52 AM schrieb Kai-Uwe Behrmann:
>> 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?

There are two reasons.

One was elaborated by Michael Sweet. The embedded profile will penetrate 
many system barriers, as it is to be honoured through the PDF/X-3 
standard. Thus it becomes highly portable accross systems and networks.
That's a big interoperability win.

The second reason is, the OutputIntent is a document property and thus 
applied per job. That can happen on client side. libCmpx implemented a 
soem functions deployable by print dialogs and applications. With that, 
they can support a very robust and non ambiguous workflow provided they 
know a useful profile for the selected printer and its driver and media 
conditions. The later can be done by Oyranos. A while ago I embedded
the needed meta data into a print ICC profile to play with the workflow.

> 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.

That's correct. We have no control about the intput side from here ;-)
This threads cares solely about the output side.
My blog post elaborates a bit about the scheme:
http://www.oyranos.org/2012/02/linux-printing/

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

You are welcome :-)

> 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.

There is not much of a hurry. sRGB is your friend.
It is up to applications, graphics libraries and toolkits to tag colours 
in the PDF appropriately or convert to sRGB as a reasonable default.

kind regards
Kai-Uwe