[Openicc] Printing Plans GhostScript / sRGB / ICC

[Kai-Uwe Behrmann]

Am 02.03.11, 22:57 +0100 schrieb Gerhard Fuernkranz:

I have the feeling, I missed most of your points, given how you usually 
write. So my reply below is just an attempt to understand you.

> Am 02.03.2011 19:36, schrieb Chris Murphy:
>> How do you communicate to pdftoraster when /DeviceRGB means sRGB vs actually meaning /DeviceRGB?
>>
>> For a PDF spool file, you can do this with /DeviceRGB without OutputIntent, vs /DeviceRGB with OutputIntent.
>>
>> For PostScript you don't have OutputIntent, so how do you differentiate for PostScript?
>>
>
> If you are in the position to create the PS or PDF files yourself, then
> you have several options to enforce a particular interpretation. For
> instance, you can set the DefaultXXX colorspace resouces _in your
> document_ (applicable to both, PS and PDF documents), overrding any
> ghostscript built-in or user-specifed DefaultXXX color spaces, or you

Is'nt this a source colour space thing in opposite of the OutputIntent, 
which is working as well as the target colour space?

> can place an OutputIntent in the document (which could be honored by the
> PS/PDF to Raster filter and used as DefaultXXX; PDF only), or you can

But that is PDF specific. It is not for PostScript available?

> even tag all source color spaces with CSAs or ICC profiles.

I actual do not understand how this would lead to a pass through.
The ICC has no way to tell a pass through from source to destination 
colour space. [I guess this is intentional and for good reason.]
The input == output rule is not rely relyable and can easily fail.

In opposite the DeviceXXX + OutputIntent is a specific means, which can be 
used for pass through inside a PDF.

> Problematic are those documens which you do not create yourself, but
> which are coming from arbitrary sources, and which you have to take "as
> is" (this could be e.g. even PS level 1 documents, or arbitrary PDF 1.x
> documents which basically comply with the PDF 1.x specs, but don't obey
> any PDF-X... conventions).
>
> I still think, if the interpretation of DeviceXXX cannot be determined
> automatically and unambiguously, then the user needs to "help" with the

Ghostscript (and likely Poppler as well) will assume sRGB for DeviceRGB 
in the absence of a OutputIntent. Thats the most important statement 
targeting at the majority of dumb applications. It will help with
disambiguation for DeviceRGB and allowes the opt-out policy to happen.

> interpretation, for instance by simply specifying the desired
> DefaultRGB, DefaultGray and/or DefaultCMYK as attributes for the print
> job [whose values are either /DeviceXXX (if pass-through is desired) or
> referring to proper ICC profiles].

This would easily clutter a default print UI.

> When printing "intelligent documents" which already enforce a particular
> interpretation, then any user-supplied DefaultXXX attributes won't be
> used anyway and will be ignored.

yes


kind regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org