[Openicc] LINUX, Gutenprint / CUPS / Color policies

[Michael Sweet]

Jan-Peter Homann wrote:
> ...
> In this case, the printerdriver will get flat-color objects, which it 
> can transform.

However, if you look at how things are done on MacOS and Windows,
and how PDF and PS documents are passed around for publishing, you
will see there is no guarantee of a single colorspace document!

Anyways, I *do* agree that the printer driver needs to get color
data in a single colorspace.

The current CUPS design allows an application to provide color data
in the most convenient form it likes.  The RIP then provides color
data in the format the driver asks for, and then the driver converts
the color data to the printer-specific data stream.  NOTHING in that
design precludes an application from "flattening" the color information
to a common colorspace, including the printer's output colorspace,
and NOTHING in that design precludes a driver from providing its own
color management.

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

Actually, no, that isn't the key.  The printer driver could be a
relatively dumb program that has no concept of color management and
just pushes bits around.

The key is to track the colorspace meta data (either a well-known
colorspace like sRGB or an application-defined profile) so that an
accurate (or acceptable facsimile) reproduction of those colors can
be done on the output device.

The application and driver are able to provide the RIP with the
necessary information to translate from source to destination.
Whether the app or driver do some amount of the work is up to them,
but any system that depends on every application to do all of the
work is doomed to failure!

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

Actually, I tend to think that most drivers are at least "average"
in their color management intelligence.  At the very least they will
perform linearization, ink management, and color separation as
appropriate for the printer.  They may not use ICC, but ICC is not
the be all and end all of color management!

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

Gutenprint is certainly a step in the right direction, however it
is not, IMHO, an ideal printer driver.  Aside from large numbers of
hand-tuned profiles, all of the driver support is still hardcoded
and there are too many options for my liking.  I've learned a lot
from its development and my other commercial printer drivers, and
those lessons-learned are reflected in the CUPS DDK drivers.

(and in case you haven't checked them out, the CUPS DDK drivers
support both sRGB and linear CMYK colorspaces and depend on the app
or RIP to provide the right color data; the device color profiles
are embedded in the PPD file, as are the necessary printer settings
for various modes and features...)

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

That is *one* way to do it, and is already supported by CUPS.

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Document Software          http://www.easysw.com