[Openicc] Introduction / Gutenprint

[Robert L Krawitz]

   Date: Sun, 10 Apr 2005 08:36:30 +0200 (CEST)
   From: Kai-Uwe Behrmann <ku.b at gmx.de>

   Am 09.04.05, 21:37 -0400 schrieb Robert L Krawitz:

   > To summarize what I think I'm hearing:
   > 
   > 1) Linearization should be performed in the driver.
   > 
   > 2) Device ICC profiling should be done in a layer between the driver
   >    and the application (Ghostscript for applications that generate
   >    Postscript, or libgutenprintui for applications that use the UI
   >    provided by Gutenprint).
   > 
   > Do people agree with this?

   Agreed.

   Sounds like an good direction if CUPS will transport some information:
   - sending a custom linearistation profile to Gutenprint
   - request a gamut profile from the CMS layer (kind of an other issue)

So the problem here is how the spooler, driver, and CMS layer talk to
each other.  Right now the spooler basically firewalls the driver from
everything else, unless you're using something like the GIMP/Cinepaint
print plugin, which incorporates the driver directly.  All of the *x
spooling systems appear to basically be designed to accept jobs and
route them to the correct printer, maybe with a little bit of job
control information on the side from a static PPD file.  The JCL is
quite limited; it allows some number of keyword/value pairs, but not
anything really extensive like curves or tables.

   For point 2, I'd like to say, an shell script or the like could be used to 
   do the transformation to pixel data (contrary to postscript/pdf or svg). 
   It should be part of the OS CMS.
   This gives some degree of flexibility. Libgutenprintui would not be the 
   right place to do such stuff directly or must become part of the CMS, wich 
   seems not very comfortable to me.

   This leads to several scenarios:
   o applications doing CM (as well called early binding, CinePaint..)
     - pixel image -> CUPS -> Gutenprint:linearisation ++

It's actually more like

pixel image -> Gutenprint:linearization/CMS -> raw data -> CUPS -> printer

where the raw data is completely uninterpreted by the spooler.
Gnome-Print at least used to be set up this way.  It certainly makes
it simple to inject the CMS process, but it also means that the
spooler has to shuffle huge amounts of data around, which is bad if
the printer's on a network and in any event consumes a lot of disk
space.  If you're printing 13x19 photographs at 2880x1440 resolution
with 7 channels and 2 bits per sample you're looking at something on
the order of a gigabyte per page or some such.  This also makes it
a lot harder to establish a pool of printers of different types but
that are color matched.

   o CM as part of the spooler system (late binding):
     A vector imagery (Scribus pdf..) -> CUPS -> renderer (ghostscript..) ->
	 Gutenprint:linearisation ++
     B pixel imagery (jpeg, tiff..) -> CUPS -> renderer (CMS - lcms..) ->
	 Gutenprint:linearisation ++

I would prefer to see this kind of scenario, but the current spoolers
don't appear to be powerful enough.  IMHO PPD files are simply too
limiting.  I'd prefer to see an architecture whereby the
printer/driver settings (with rich data types) are bundled up with the
job and sent by the spooler to the driver, using something like the
Gutenprint parameter system or something else everyone can agree on.
This would allow for interaction between the driver (by proxy) and the
user.

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