[Openicc] CUPS Color Management under Linux... (what is to do ?)

[Gerhard Fuernkranz]

Am 10.02.2011 21:03, schrieb Hal V. Engel:
>
>
> GhostScript has provisions for device links
>

My understanding is that -sDeviceLinkProfile=... is intended for
proofing, i.e. the given device link is applied after any other color
transformation in order to carry out the the proofing transformation
(e.g. from an emulated printing press color space to an inkjet printer
color space). The handbook also says that it's not fully supported yet,
whatever this may mean.

> and I think it might be possible to use it's command line args to
> force null transforms since it allows for substitutions on the command
> line for what profiles will be used with DeviceXXX objects.
>
>
> Also GhostScript appears to use a set of default profiles for
> DeviceXXX objects which can be over ridden by command line args. So it
> will be nessary to force these settings for things like profiling charts.
>

You need to override the the DefaultXXX ColorSpace resources anyway,
according to your needs (not just when printing profiling charts). It
seems that the gs 9.0 built-in DefaultRGB and DefaultCMYK are sRGB and
SWOP. These are certainly reasonable defaults, but still they don't fit
any use case.

For instance, when printing a PDF documented that was intended for a
ISOcoated, and which uses DeviceCMYK colors, then you need of course
DefaultCMYK set to ISOcoated and not to SWOP (i.e. DeviceCMYK should be
interpreted as ISOcoated then).

I'm not sure either whether gs when used as PDF "reader" derives
DefaultXXX from the output intents (if present in the document). I
rather guess it does not, so it's likeley still necessary to set
DefaultXXX explicitly. Quote from the PDF 1.7 spec:

    "The ICC profile information in an output intent dictionary
    supplements rather than replaces that in an ICCBased or default
    colour space (see 8.6.5.5, "ICCBased Colour Spaces," and 8.6.5.6,
    "Default Colour Spaces").
    [...]
    The data in an output intent dictionary shall be provided for
    informational purposes only, and conforming readers are free to
    disregard it"

When printing profiling charts, the DefaultRGB(CMYK/Gray) resource
(depending on the device's process color model) should be set to
/DeviceRGB(CMYK/Gray), in order to avoid remapping of
DeviceRGB(CMYK/Gray) to CIE-based default color spaces.

A PDF document to be printed also has the opportunity to override the
DefaultXXX colorspace resources, i.e. the document can either enforce
e.g. a particular colorimetric interpretation of DeviceXXX colors, or
prevent a special interpretation of DeviceXXX colors appearing in the
document (e.g. for profiling charts). Of course this works only, if the
document explicitly makes use of this opportunity.

I'm not sure whether -dUseCIEColor=true/false is honored by gs when
rendering PDF documents. For PostScript it should be honored for
compliance with the PLRM and is supposed to turn the remapping of
DeviceXXX to DefaultXXX on or off, but the PDF spec does not define a
"UseCIEColor" flag at all, and DeviceXXX colors in PDF documents are
generally supposed to be remapped to the color space associated with
DefaultXXX if the latter is defined in the ColorSpace resource dictionary.

Regards,
Gerhard

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/openicc/attachments/20110218/9e8ee47a/attachment.html>