[Openicc] LINUX, Gutenprint / CUPS / Color policies

[Robert L Krawitz]

   Date: Thu, 14 Apr 2005 11:11:41 -0400
   From: Michael Sweet <mike at easysw.com>

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

   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.

Except that it's very hard to pass arbitrarily complex data (ICC
profiles or linearization curves) through CUPS to the driver.  So if
someone puts a lot of effort into creating good linearization curves,
it's going to be very hard to actually use them.

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

Yes, but if there's only an 8-bit data path between CUPS and the
driver (as is the case right now) there is an to doing the color
management in the driver: greater precision.

   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!

Agreed, but I'm not sure where best to draw the line.  The
GIMP/Cinepaint Print plugin is (close to) one extreme: a lot of the
work is done in the application (albeit in the form of a plugin with a
fairly simple API), but with a lot of flexibility about specifying
curves etc., while CUPS is at the other end (a completely generic
interface, with the driver firewalled off from the application, but
much less flexibility).

   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.

The hand-tuned profiles are a compromise.  There hasn't really been a
good color management solution available, and we have to get good
quality somehow.  Also, generating all these profiles for so many
printer/paper/resolution/etc. combinations is a huge amount of work,
so an algorithmic reduction in profile space is necessary.  I agree
that the hard coded driver support is a bug.  I've made it at least
look more like data for the Epson driver in 5.0, and I want to turn it
into real data (XML files) for 5.2.  As for the options, I'm open to
simplifying the interface by improving default settings and such, but
in terms of actually reducing the knobs available to the user, we
basically agree to disagree.  Commercial RIP's aren't particularly
simple when you really want to tune them, from what I understand.

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

There's a lot to be said for the spooler to translate the color into a
standard color space by default (unless, of course, the user really
wants to specify printer-specific color) and the driver working from
that color space.

-- 
Robert Krawitz                                     <rlk at alum.mit.edu>

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf at uunet.uu.net
Project lead for Gimp Print   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton