[Openicc] Linux printing

Tue Feb 28 11:06:33 PST 2012

On Tue, Feb 28, 2012 at 10:02 AM, Kai-Uwe Behrmann <ku.b at gmx.de> wrote:

> 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.
>
>
I guess we are talking about two different things here.  There are two
"override" conditions.

Case 1:  Suppose I have a source color space in a PDF file that is ICC
based.  It is possible in Ghostscript to actually override that source
color ICC profile and replace it with a different ICC profile.  To do this,
requires the use of a command line option -dOverrideICC.   This is the type
of command line option that one really would never use if they had a
properly defined PDF file.  Apparently the customers for some RIP vendors
receive all sorts of garbage PDFs and so they need to have the capability
to override what the file says the colors are.  I agree that in a perfect
world this would not be needed, but unfortunately I don't write all the PDF
creation software.   User beware when they use this option and I doubt this
command line option would be used by anyone but particular RIP vendors.

Case 2:  Now we are talking about Output Intent.  A PDF file can have
multiple output intents and the ICC profile may or may not be included in
the output intent dictionaries.   Because of this ambiguity, Ghostscript
has been  ignoring the OutputIntent.  A work around for this has been to
use Ghostscript to parse and dump the ICC profiles contained in the
OutputIntent dictionaries using a tool called extractICCprofiles.ps in
Ghostscript's toolbin directory and then to specify on the command line the
particular output intent profile that you wished to used for the device and
for the default source color space.  For example, if there was a CMYK
output intent dictionary in the file and it was the one that I wished to
use, then I could first extract it using the tool.  Then I would want to
specify -sOutputICCProfile=my_device_profile.icc
-sDefaultCMYKProfile=cmyk_profile.icc -sProofProfile=cmyk_profile.icc where
obviously cmyk_profile.icc is the profile that I extracted from the
dictionary and assuming that we are actually printing to a device that has
a profile called my_device_profile.icc  .

Now, I am in the process of implementing automated use of the OutputIntent
in Ghostscript.   Since people are used to having Ghostscript provide a
certain result, this new use of the OutputIntent by Ghostscript will be
initially invoked through the use of a command line option
-dUsePDFX3Profile=#  where # specifies which OutputIntent to use.   Now, if
one does NOT specify a particular output ICC profile for their device, the
file will be rendered to the output intent color space (assuming the device
process color space matches the OutputIntent color space i.e. CMYK vs
RGB).  If someone DOES specify an ICC profile for their device using
-sOutputICCProfile=my_device_profile.icc, then Ghostscript will treat the
output intent as if it were the proofing profile.   That is, rendering
through the output intent profile and end up in the color space specified
for the device profile.  This use of the OutputIntent as a proofing profile
will also occur if the process color model of the target device is
different than the OutputIntent color space.   In this sense, the
"override"  by the device profile is not really an override but simply an
attempt to make proper use of the output intent on the target device giving
the user a view of how the file was intended to look when printed/viewed on
their target device.

>
>  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
>
> ______________________________**_________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/**mailman/listinfo/openicc<http://lists.freedesktop.org/mailman/listinfo/openicc>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/openicc/attachments/20120228/440c7799/attachment.htm>