[Openicc] printing GUI vs. printerdriver, LINUX colorinfrastructure

[Leonard Rosenthol]

At 10:02 PM 4/17/2005, Robert L Krawitz wrote:
>    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 my view - a RIP could be either.  That's how it is "in the real 
world"...Some RIPs are responsible for producing a "generic raster" (eg. 
TIFF, CT/LW) while others product printer-specific bits.

         I don't believe that it matters for the sake of this 
discussion.  WHATEVER is responsible for producing a single colorspace 
raster image from the API/PDL is the RIP.


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

         Most certainly.


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

         No.  I see GP as a post-RIP process - the process responsible for 
taking the RIPs output and preparing that for printer.


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

         Not in the scenario of a dumb raster device, no.



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

         Exactly! pstoraster has limitations today, and so GP has to do 
more work on its end to make up for that.


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)