[Openicc] Linux printing

Kai-Uwe Behrmann ku.b at gmx.de
Tue Feb 28 10:02:51 PST 2012


Am 28.02.12, 09:25 -0800 schrieb Michael Vrhel:
> On Tue, Feb 28, 2012 at 9:08 AM, Chris Murphy <lists at colorremedies.com>wrote:
>> On Feb 27, 2012, at 10:52 PM, Michael Vrhel wrote:
>>
>>> 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.
>>
>> For what it's worth, the idea of overriding embedded profiles in a
>> document is a big problem. If the wrong source profile is embedded, the PDF
>> needs to print like crap, and the offending user or application that
>> produced the PDF needs to fix their error.
>>
>
> The fact is that the world is a big place and there are software RIP
> vendors that use Ghostscript in their products and they need to have this
> capability.   It is an option that one has available and requires a special
> command line option to invoke.  In its vanilla calling form, Ghostscript
> makes use of all the embedded ICC profiles in PDF.

Honestly I share Chris' objection.

I would feel much better, if you design the options in a way, that 
overriding a embedded profile will not happen even if a external profile 
is specified :-)
So I think a explicite option to ignore the embedded profile, beside a 
external subordinate specified profile would be my wish.

# the first case works compliant to PDF/X standard
gs --output-profile-if-no-embedded-is-found=XXX
# the second case breaks willingly the PDF/X standard and is
# not prominently documented
gs --output-profile-if-no-embedded-is-found=XXX --ignore-embedded

Hope that satisfies both concers.

>> Hacks that ignore embedded profiles is what destroyed the original PNG
>> based color management implementation. Apps wrote out PNGs with bogus color
>> information, and when honored by viewing applications the images looked
>> whacky. So PNG viewer application developers started to ignore the
>> color/gamma metadata in PNG, rendering that whole paradigm entirely useless.
>>
>> Second guessing embedded metadata is just like second guessing actual
>> data. Apps, RIPs, printers themselves are not ignoring RGB 232, 50, 100 in
>> favor of some other values. They should not be ignoring embedded profiles
>> in favor of some other values either.
>>
>> The mere option of overriding embedded profiles is like handing developers
>> and users razor blades and telling them to go play out on the freeway. It
>> will regress the consistency of color management, by making it even less
>> consistent than it already is.
>>
>
> My comment on your analogy is to say that if one doesn't know the proper
> way to use a tool and fails to RTFM then you deserve what you get, which is
> cut and run over :) .   By default Ghostscript is designed to honor all the
> embedded color information.

kind regards
Kai-Uwe


More information about the openicc mailing list