[Openicc] LINUX, Gutenprint / CUPS / Color policies

[Jan-Peter Homann]

Hello Mike, hello list
As I wrote, in the last mail, I recommend strongly to do 
colortransformtions for individual objects in the application, where the 
complete document is build.

colormanagement for documents, where each object can hav his own profile 
makes only sense, if the applications for document-cration has following 
features:
- softproof of all objects with correct use of profiles and intents
- flattening object-color to one document-colorspace during file-export
- flattening object-color to one document-colorspace during printing

In this case, the printerdriver will get flat-color objects, which it 
can transform.

The key of transparent and professional colormanagement for printing is 
a printerdriver, which allows linearization and use of profiles 
according the media/driver-setting.

All other solutions are workarounds, because a lot of printer-drivers 
are today dumb in the field of color management.

As gutenprint is coming more and more near to an ideal printerdriver, we 
should support to do printer colormanagement here.

if we have a queue
application->CUPS->Ghostscript->Gutentprint we need technology, that 
Gutenprints automaticly gets the document-colorspace, from the 
application, which is sending the data.

This is transparent an easy configurable colormanagement for printing.

:-) Jan-Peter




Michael Sweet schrieb:
> Jan-Peter Homann wrote:

>> In strongly recommend to do this in the printer-driver and not in the 
>> application, in the RIP or in CUPS. This should be part of the 
>> printer-driver.
> 
> 
> This actually isn't what I would recommend - PDF documents, in
> particular, can have images and colors in many different colorspaces
> using many different profiles - at some point you need a common
> colorspace with the printer driver so that the color info is
> accurately conveyed.
> 
> The whole purpose of the CUPS raster driver interface is to *simplify*
> the color management interface, such that a RIP can provide the most
> convenient color data for the driver, not force color management on
> it.
> 
> Nothing in the CUPS driver interface prevents a driver from doing its
> own color management (at whatever level), but the RIP has to deal with
> the multiple input colorspace scenario regardless of the driver's
> abilities.
> 
>> ...
>> 3. Path-through of the document-colorspace to the printer-driver
> 
> 
> That won't work, simply because most printers are dumb raster devices
> and the drivers need raster data in a single colorspace, not a mix.
> 


-- 
--

homann colormanagement ------ fon/fax +49 30 611 075 18
Jan-Peter Homann ------------- mobile +49 171 54 70 358
Kastanienallee 71 ------- http://www.colormanagement.de
10435 Berlin --------- mailto:homann at colormanagement.de