[Openicc] Printing Plans GhostScript / sRGB / ICC

Gerhard Fuernkranz nospam456 at gmx.de
Wed Mar 2 13:57:50 PST 2011


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
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
even tag all source color spaces with CSAs or ICC profiles.

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
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].

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.

Regards,
Gerhard



More information about the openicc mailing list