[Openicc] printing GUI vs. printerdriver, LINUX colorinfrastructure

[Gerhard Fuernkranz]

>          Conversion of application API calls and/or PDL to a raster image 
> are done either by a RIP OR in the actual printing device (eg. Postscript 
> printer).
> 
>          Many RIPs have integrated color management. This is esp. 
> important in RIPs for languages like Postscript and PDF - where (as has 
> been noted before) individual objects may be described in different 
> colorspaces.  The "flattening" of the colorspaces needs to take place
> in  this process OR potentially somewhere up the workflow with native
> language processing tools (eg. a PDF/X compliance system).

Agreed. Actually I even think, a printing subsystem which claims
full PS level3, PDF (including PDF/X-3) compliance, has not really
the option, not to support color management in the RIP (or in the
printer, if the RIP is located in the printer). Of course the
RIP must also still accept e.g. a "pre-flattened" CMYK document.

> >In the printing GUI, the user should specify, which
> >way of colormanagement he is using.
> 
>          I don't see how that is possible...

If we consider a printing GUI as part of the application
(i.e. as a set of common library functions which are
used by several applications), then IMO it has the option
how to send the printed objects downstreams, either tagged
with the original color space, or converted to the printer's
color space.

Regard,
Gerhard

-- 
+++ NEU: GMX DSL_Flatrate! Schon ab 14,99 EUR/Monat! +++

GMX Garantie: Surfen ohne Tempo-Limit! http://www.gmx.net/de/go/dsl