[Openicc] printing GUI vs. printerdriver, LINUX colorinfrastructure

[Leonard Rosenthol]

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



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

         API/PDL -> printer language is a separate process that takes (in 
my view) INSTEAD of a RIPping process when working with a non-raster 
printing device.  A common case of this is pdf2ps, when printing to 
Postscript device on Mac OS X.


>The part that I'm interested in is where the color management should be 
>performed:

         Depends on who you talk to ;).

         I don't think there is a single answer - it is entirely dependant 
on the printing workflow involved.   What type of printer is involved 
(raster or vector)?   What type of data is being received into the print 
stream?  Single colorspace raster?  Single colorspace PDL?  Multi-colored 
PDL?  Are there any profiles involved? etc.

         IMO, color management has to happen (initially?) at the time of 
RIPping (creation of a single colorspace raster image).  It has to happen 
here, because this is the last time you have the highest fidelity color 
information associated with specific "objects". This may be in the source 
application.  It may be in the spooler (CUPS's pstoraster).  It may be in a 
specific RIP module.  Or possibly even in the actual printer.

         That said, because the "RIPping" process may take place w/o any 
information about the final output device (eg. the printer's profile), 
there would be the need to perform a secondary color conversion 
(potentially with DeviceLink profiles, and/or non-ICC-based conversion 
techniques) from the profile used to RIP to the one for the printer.  This 
is not only useful for something like SWOP->ISO Coated coated, but esp. for 
CMYK->HiFi/Hexachrome type output.


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

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


Leonard

---------------------------------------------------------------------------
Leonard Rosenthol                            <mailto:leonardr at pdfsages.com>
Chief Technical Officer                      <http://www.pdfsages.com>
PDF Sages, Inc.                              215-938-7080 (voice)
                                              215-938-0880 (fax)