[Openicc] Linux printing

Kai-Uwe Behrmann ku.b at gmx.de
Mon Feb 27 22:52:42 PST 2012


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. A 
documentation how to customise a pdftoraster filter and perhaps even how 
to configure it from the cups print client might be interessting to 
people, who want to use these features in a late binding workflow.

> I am in the process right now of adding in proper Output Intent handling into 
> Ghostscript for cases when the profile is included in the output intent 
> description.  This will be available in the 9.06 release this August (earlier 
> with patch on 9.05).   The work that I see you have going on may fit in 
> nicely with the cases where the Output Intent does not contain the ICC 
> profile but it is off in a profile data base.  In this case, a call to

Oops, I try to understand and therefore repeat. You say that the PDF 
OutputIntent may not contain a ICC profile and is not present in the PDF?

> Ghostscript with the proper options specifying the ICC profile for the 
> particular Device color and for the output Device would be in order.

Only in absence of the OutputIntent is a external specified profile 
accepted by Ghostscript?

As you know the OutputIntent is internal to the PDF. Does Ghostscript 
detect the OutputIntent and skip any output profile from the command line? 
Or may Ghostscript provide a way to detect a OutputIntent, in order to 
help the calling pdftoraster filter to detect the OutputIntent and skip 
any device profile options itself?

> If you want to read about the current color command options available in 
> Ghostscript 9.05 see
>
> http://ghostscript.com/doc/current/GS9_Color_Management.pdf
>
> Kind Regards,
>
> Michael

kind regards
Kai-Uwe


More information about the openicc mailing list