[Openicc] LINUX, Gutenprint / CUPS / Color policies

[Robert L Krawitz]

   Date: Fri, 15 Apr 2005 08:47:42 +1000
   From: Graeme Gill <graeme at argyllcms.com>

   Jan-Peter Homann wrote:
   > First point is, where is the colortransformtion from document-colorspace 
   > to printer-colorspace done.
   > 
   > In strongly recommend to do this in the printer-driver and not in the 
   > application, in the RIP or in CUPS. This should be part of the 
   > printer-driver.

   I can't agree with you there. The whole purpose of something like a
   PostScript Rip is to transform a (relatively) device independent
   page description into a raster for a specific device.

I don't think we all share a common understanding of what all the
terms mean, and that that's tripping us up here.

   It has all the machinery to do so, and is in the right place to
   it. Now it could be that in many systems the RIP is being placed at
   an awkward point in the workflow, further away from the device than
   is really desirable.

   A correct workflow (assuming the print driver
   produces a page description format) is:

   Application -> print driver -> spooler -> RIP -> device.

To my operating system background, this seems strange.  To me, a
"driver" means a low-level component that actually provides signalling
and protocol to a device.  Typically this would be based in a kernel,
but in the case of a printer, it would make sense for it to be in user
space -- usually it doesn't actually have to manage printer behavior
in real time; it just has to generate the right data (more like a
network driver, which might do TCP/IP but not actually manage
card-level interrupts or real-time behavior or the like), so there's
no real reason to stick it in the kernel and lots of good reasons not
to.

By that measure, the very last component in the chain before the
device *has* to be the printer driver (well, not quite -- there's the
port driver, such as a USB or parallel port, but we'll assume for now
that that simply passes data between the higher level driver and the
physical device and that it's a transparent pipe).  If the RIP
generates printer-specific data, then by definition (mine, at any
rate) it encapsulates the driver.  A driver wouldn't produce a generic
page description language; it would produce the necessary protocol and
signalling to drive the physical printer device.

Now, if by "print driver" you mean "something that generates a generic
page description language from a high level API", then your diagram
makes sense, but the names just don't sound right to me.

"Raster image processor" sounds to me like something that takes data
in a high level page description language and outputs some kind of low
level raster data.  In the CUPS approach, there's a generic RIP
(pstoraster, imagetoraster) and a printer-specific component
(rastertogutenprint, for example, which I would call a "driver").  It
looks like you're combining those two into a single component you call
a "RIP".

I personally think of the "printer" as the combination of the physical
printer and the appropriate driver.  Again, this is my operating
system background -- when applications talk to a "device", they really
talk to the device driver, which actually manages the physical device.

Maybe there are good reasons for your terminology that I don't see,
but in that case we need to agree on exactly what the components are
and what we're going to call them.

   The setting of the device color profile is an administration task
   of the RIP/device combination.

I *think* that we're all in agreement that the device color needs to
be generated somewhere within the box you call a "RIP", but the issue
that Jan-Peter and I are thinking about is *where* within that box the
device color profile is applied.  It could be within the generic part
(what I call the "RIP"), or within the device-dependent part (what I
call the "driver").

   Putting the RIP ahead of the spooler (and presumably on the client
   box) is not a natural way of doing things, and introduces exactly
   the sorts of administration issues currently being discussed.

Maybe and maybe not.  One could also think of the spooler as nothing
more than a data link layer, logically no different from a USB or
parallel port (again, here's my system background showing) that's
responsible for taking data from one place and putting it somewhere
else.  If the physical printer doesn't need bidirectional signalling,
this model works just fine, albeit inefficiently from a data transfer
perspective.  In this case, the spooler is basically a network link or
router, and plays no part in the color management.

   If there is a compelling reason to RIP on the client and then spool
   to a print server, then you really need to get the device/print
   spooler to have the color & device configuration communicate back
   to the RIP the details of the device, so the user doesn't see this
   aspect.

This is what I would call "discovery" or "device probe".  Let's assume
for now that we know exactly what the hardware device configuration
is, to simplify matters.  In some cases, we aren't going to know
anything more than that, perhaps the printer model at best for a
typical inkjet printer.

Printer discovery's not unimportant, but we're not going to solve it
here.  If it has color management aspects, we should be telling the
folks working on that what our needs are.  I think that for a first
step we don't need it; we can assume a static hardware configuration.

   > Second point is, where are the profiles for the printing process 
   > (printer-type, medium, driver-settings) are specified.
   > 
   > This should be part of the printer-driver and not CUPS !!!
   > 
   > The whole discussion about profiles in CUPS makes only sense, if we use 
   > CUPS for the colortransformation from document-colorspace to 
   > printer-colorspace because the printer-driver is dumb in the field of 
   > colormanagement.
   > 
   > If our goal is transparent colormanagement for printing, we have to 
   > discuss the colorpolicy for
   > 1. appplication
   > 2. RIP
   > 3. CUPS
   > 4. printer-driver
   > 
   > If a standard-installtion of all this 4 software-part gives the 
   > possibility of profile-configuration and inetraction of color-settings, 
   > this is total chaos from the view of the user.
   > 
   > If we want transparency I would recommend following GUI:
   > 1. colortransformation from individual objects to the 
   > document-colorspace in the application

   Definitely not. Rendering to the device is nothing to do with the
   application. The application should be able to concentrate on what
   it is printing, not the technical details of the output device
   (unless of course the application is deliberately taking on this
   task for some special purpose).

I don't read that at all as what Jan-Peter is saying.  He's saying
that the application should transform the entire document into a
single color space, rather than passing off objects in multiple color
spaces to lower levels.

   > 2. No profile configuration in RIP and CUPS
   > 3. Path-through of the document-colorspace to the printer-driver
   > 4. Colortransformtion from document-colorspace->printer-colorspace in 
   > the printerdriver.

   I think you are on completely the wrong track. Device details
   should ideally be kept as close to the device as possible, with the
   aim of isolating entities upstream from details that they don't
   have to be concerned about.

I don't think we're particularly in disagreement with that statement
as is.  I think we need to determine what details upstream entities
*have* to be concerned about (clearly page size and color
vs. monochrome are two of these) and what details they might *want* to
influence (I think we're all over the map here, with my
anarcho-libertarian take at one extreme).

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