[Openicc] printing GUI vs. printerdriver, LINUX colorinfrastructure

[Leonard Rosenthol]

At 08:33 AM 4/16/2005, Jan-Peter Homann wrote:
>The main points of this mail together:
>-------------------------------------
>The printerdriver should be able to use CMYK(cm) linerizations and 
>icc-profiles
>- colormanagement for printing should be done in the printerdriver after 
>ripping

         It may already be too late for good quality color management at 
that point :(.

         If the data coming into the RIP is in RGB or LAB (or ...), then 
you want to do the best quality/fidelity conversion to CMYK (for example) 
RIGHT THEN (in the RIP).  If, instead, you were to let the RIP do "less 
then optimal" conversion to CMYK - hoping to fix it up in the driver, 
you're asking for bad color results.

         You need to do the conversions right the first time...


>- the document-colorspace should be sended from
>application->printerGUI/CUPS->RIP->printerdriver
>- the rendering intent for printing should be specified in the printingGUI 
>and sended the same way like the document colorspace

         Documents entering CUPS and/or the RIP may not have a single 
colorspace and/or rendering intent.  This is already the case today with 
many applications.


>- The printerdriver should use devicelink-profiles if hardcoded 
>colortransformations are necessary.

         A great idea - ASSUMING that you can predict the incoming 
colorspace.  OR are you expecting to have multiple DL profiles available 
for a variety of incoming spaces?


>This printing architecture would be in the field of colormanagement more 
>flexible, powerful and transparent than the actual printing architecture 
>in Windows or Mac OS X.

         Than Windows, sure.

         What makes you think this is a better color managed solution than 
Mac OS X?   Esp. since in Mac OS X, EVERY OBJECT going into the printing 
system (CUPS) has an attached ICC profile associated with it that is then 
used by the RIP (pdftoraster) to correctly render the output colorspace 
using profiles provided by the printer.   (Correct, Michael?)


Leonard

---------------------------------------------------------------------------
Leonard Rosenthol                            <mailto:leonardr at pdfsages.com>
Chief Technical Officer                      <http://www.pdfsages.com>
PDF Sages, Inc.                              215-938-7080 (voice)
                                              215-938-0880 (fax)