[Openicc] printing GUI vs. printerdriver, LINUX colorinfrastructure

[Robert L Krawitz]

   Date: Sun, 17 Apr 2005 19:56:59 -0400
   From: Leonard Rosenthol <leonardr at pdfsages.com>

   At 08:33 AM 4/16/2005, Jan-Peter Homann wrote:
   >The printerdriver is driving the printer directly.

   As was pointed out by someone else - there are two types of
   "printer drivers" in existance today.  One that converts from
   application API calls to some form of page description language
   (PDL) (eg. Postscript or PDF) - this is what GnomePrint, the KDE
   print manager, the Adobe PS driver on Windows, etc. do.  The second
   is responsible for the hardware connectivity to the printer.

   In our discussions, the latter is not important (we don't care how
   the bytes get to the device) - only the former is...

   >  Mainly this is the rasterization for the printed dots, some kind of 
   > colormanagement

   Conversion of application API calls and/or PDL to a raster image
   are done either by a RIP OR in the actual printing device
   (eg. Postscript printer).

When I think of a "printer driver", I (and I suspect at least a few
others here) am primarily thinking of the back end of the RIP, which
is yet another meaning.  Again, my view of the printing architecture:

API => PDL => spooler => raster => printer data => printer

Basically, I think of the combination of printer + driver (where I'm
using "driver" in the Gutenprint sense, as a piece of software that
generates printer-specific commands from a generic high-level raster
or vector data stream) as a "virtual printer".  To CUPS, it doesn't
really matter if the printer natively takes 8 or 16 bit raster data or
a driver emulates this.

I fundamentally don't like using the term "RIP" to encompass the
entire process of converting PDL (or API) to the low level printer
language.  I'm aware that there are RIP's sold in the Window market
that provide the entire soup to nuts conversion, but usually (at least
in the UNIX/Linux world) there's a generic component that translates a
PDL (Postscript, say) to a generic raster format and a
printer-specific component that translates that generic raster format
to printer-specific format.  As the project lead for Gutenprint, I
have a particular interest in the latter and a passing interest in the
former insofar as it affects how I do the latter.

   Many RIPs have integrated color management.  This is esp.
   important in RIPs for languages like Postscript and PDF - where (as
   has been noted before) individual objects may be described in
   different colorspaces.  The "flattening" of the colorspaces needs
   to take place in this process OR potentially somewhere up the
   workflow with native language processing tools (eg. a PDF/X
   compliance system).

The part that I'm interested in is where the color management should
be performed: in Gutenprint (i. e. the back end of the RIP) or at a
higher level (the front end of the RIP, or even higher level).  If the
answer is that it should all be performed in the front end of the RIP,
and that the back end should content itself with simply accepting
linear levels and laying down the appropriate amount of ink, that's
fine by me -- I'm done with my piece.  However, I don't think that
that's the right answer: the high level part of the RIP doesn't
generate 16 bit output yet, and 8 bits of literal linear data makes
for very coarse resolution in the highlights.

So the real question that I'm interested in is how the color
management support should be distributed between the high level of the
RIP (let's use the specific term "pstoraster" for this since it's a
known instance of what I'm talking about) and the low level (let's use
the term "Gutenprint").

   >As described in mails before, we have four main possibilities to transform 
   >color for printing:
   >1. colormanagement in the application
   >2. colormanagement as CUPS-filter
   >3. colormanagement with CSA/CRD in the PostScript-RIP
   >4. colormanagement in the printerdriver

   True, though I doubt #4 actually happens (assuming you mean driver
   as hardware controller). If you mean the app->PDL component, then
   yes, that can include color management.

Again, Jan-Peter and I are using "driver" and "RIP" in a different way
from what you appear to be.

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