[Openicc] LINUX, Gutenprint / CUPS / Color policies

[Graeme Gill]

Robert L Krawitz wrote:

>    From: Graeme Gill <graeme at argyllcms.com>

>    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

Sorry, there is term overload confusion in the word "driver"
when applied to printing workflows. "driver" is the label
often given to two different elements in a printing workflow.

One is the Application-API level element that lets applications
generate printed output. One might have a Postscript driver,
a PCL driver, a GDI driver etc.

The other is the lower level "Device driver", which glues more
general print system elements (spooler, RIP) to a particular
printing device. In some context there are even two device drivers,
one operating at the user process level, and a "real" device
driver in the kernel sense. If the transport to the device is
via some more conventional means (say USB, ethernet, Firewire,
parallel port), then of course no device specific kernel driver may be
needed.

To redraw my workflow more explicitly:

Application -> print driver -> spooler -> RIP -> device driver -> 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.

Yep. Not my fault. That's how stuff has ended up being labelled.

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

Most RIPs are both device generic and device specific. They have
general machinery that can be applied to processing the print data
for a specific device. The vendor of a RIP provides the machinery
and a way of customizing it, the user of the RIP customizes it
for a specific set of device. That customization can be regarded as
being part of the device driver. In the context of raster data,
the "RIP" may be so trivial that it isn't really called a RIP,
or the print driver may be arranged such that it does everything,
and takes the place of the RIP and possibly even the device driver.

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

The term "printer" has even more possible meanings than "device" in the
context of multiple operating systems and environments, some of them quite
contradictory. It's terribly OS and vendor dependent.

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

Mainly dealing with print systems on MSWindows and Apple systems,
as well as dealing with pre-press workflows.

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

You're perfectly right that this is a viable way of working. It seems to
introduce administrative issues though. The natural place for the device
color configuration is attached in some way to the device (not necessarily
physically, but logically. The alternative would be anarchy, with each user
doing their own profiling and configuration of the device) If the RIPing is
being distributed, then the information about the device configuration needs
to be distributed to the RIPs, so that they can set themselves up for the
device. You need a protocol to communicate that information to the RIPs.
I get the impression that no standard protocol exists for this.

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

I'm sympathetic to "get something working rather than just plan the perfect
system", but I'm not sure this aspect can really be just ignored, if we
want to see color managed printing under open OS's.

I do see all this as being only of peripheral interest if the task is
to provide color management facilities in an OS. Such facilities don't
really need to know anything about printing etc. It is just a resource
for components that do deal with all that stuff.

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

A lot of this is out of our hands in any case. Other forces (Adobe)
have set the standards. PDF is a print representation format, and
it has a variety of ways of representing color in a document. PDF
represents a super-set of most other approaches of representing a
printed page. It also represents a nice half way point, so that the
application only has to take minimal consideration of the capabilities
of the device, while leaving the very specific conversions (such as
resolution, color conversion) up to elements that have device specific
information available to them (RIP and device driver).

An application can certainly choose to convert all it's elements
to one color space, or even the output device colorspace, when
printing to something like PDF, but the workflow does not force
this on the application.

Graeme Gill.


Graeme Gill.