[Openicc] printing GUI vs. printerdriver, LINUX colorinfrastructure

[Robert L Krawitz]

   Date: Sun, 17 Apr 2005 21:37:29 -0400
   From: Leonard Rosenthol <leonardr at pdfsages.com>

   At 08:59 PM 4/17/2005, Robert L Krawitz wrote:
   >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

   Assuming a raster output device, then I would agree with this
   architecture.  (I guess it might even be a PDL-based one if you
   assume that raster and printer data are occuring on the device
   itself).

To be specific, I'm thinking about dumb raster-based devices, or to be
more precise, inkjet printers.

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

   No, I agree with you.

   A RIP is the process of turning API/PDL into a raster image...

What *kind* of raster image?  A generic raster image (8/16 bit
RGB/CMYK/whatever), or printer-specific bits (on or off dots of
specific inks, sent in a specific sequence, with appropriate paper and
head positioning commands), or both as one?  I want to be very precise
about terminology, because otherwise we're all talking past each
other.

In your view:

* Is pstoraster part of the RIP (yes/no)?

* Is Gutenprint part of the RIP (yes/no)?

* Is anything else part of the RIP (yes/no)?

  + If yes, what?

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

   Well, in the best of all possible worlds, Gutenprint (GP) would
   provide pstoraster (P2R) with the printer profile and it (P2R)
   would then perform color conversion from the source colors directly
   to printer profile.  And then GP would just pass a raw bitmap along
   to the physical device.

If pstoraster is generating 16 bits for each physical channel of the
output (CMYK, CMYKcm, CMYKRBL, or whatever), and pstoraster knows how
to linearize the output, and sets the right density for the paper type
and resolution, that's fine -- Gutenprint need merely dither it down
to however many levels the printer physically supports (usually either
1 or 2 bits, so 1 or 3 levels plus off), format it appropriately, and
let fly.  If pstoraster is less capable -- and currently it is --
Gutenprint has to do more.

Levity aside, this is important.  I certainly don't want to do
unnecessary work in Gutenprint, but at the same time achieving top
quality output is our primary goal.  So I want to find the right place
to draw the line and all that.

   However, we all know that it doesn't work that way today - P2R
   (Ghostscript on Linux) sucks when it comes to color management NOR
   does it support the passing of an output profile.  As such, GP is
   going to have to do its best to clean up after P2R using as many
   techniques as it can...

Some of our techniques might make you retch, but you know what they
say about making sausage...

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