[Openicc] LINUX, Gutenprint / CUPS / Color policies

[Graeme Gill]

Jan-Peter Homann wrote:
> First point is, where is the colortransformtion from document-colorspace 
> to printer-colorspace done.
> 
> 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.

I can't agree with you there. The whole purpose of something like
a PostScript Rip is to transform a (relatively) device independent
page description into a raster for a specific device.

It has all the machinery to do so, and is in the right place to
it. Now it could be that in many systems the RIP is being placed
at an awkward point in the workflow, further away from the device
than is really desirable.

A correct workflow (assuming the print driver
produces a page description format) is:

Application -> print driver -> spooler -> RIP -> device.

The setting of the device color profile is an administration
task of the RIP/device combination.

Putting the RIP ahead of the spooler (and presumably on the
client box) is not a natural way of doing things, and
introduces exactly the sorts of administration issues
currently being discussed.

If there is a compelling reason to RIP on the client
and then spool to a print server, then you really need
to get the device/print spooler to have the color & device
configuration communicate back to the RIP the details of
the device, so the user doesn't see this aspect.

> Second point is, where are the profiles for the printing process 
> (printer-type, medium, driver-settings) are specified.
> 
> This should be part of the printer-driver and not CUPS !!!
> 
> The whole discussion about profiles in CUPS makes only sense, if we use 
> CUPS for the colortransformation from document-colorspace to 
> printer-colorspace because the printer-driver is dumb in the field of 
> colormanagement.
> 
> If our goal is transparent colormanagement for printing, we have to 
> discuss the colorpolicy for
> 1. appplication
> 2. RIP
> 3. CUPS
> 4. printer-driver
> 
> If a standard-installtion of all this 4 software-part gives the 
> possibility of profile-configuration and inetraction of color-settings, 
> this is total chaos from the view of the user.
> 
> If we want transparency I would recommend following GUI:
> 1. colortransformation from individual objects to the 
> document-colorspace in the application

Definitely not. Rendering to the device is nothing to do
with the application. The application should be able to
concentrate on what it is printing, not the technical
details of the output device (unless of course the
application is deliberately taking on this task for
some special purpose).

> 2. No profile configuration in RIP and CUPS
> 3. Path-through of the document-colorspace to the printer-driver
> 4. Colortransformtion from document-colorspace->printer-colorspace in 
> the printerdriver.

I think you are on completely the wrong track. Device details should
ideally be kept as close to the device as possible, with the aim
of isolating entities upstream from details that they don't have to
be concerned about.

Graeme Gill.