[Openicc] printing GUI vs. printerdriver, LINUX colorinfrastructure

[Graeme Gill]

Bob Friesenhahn wrote:
 > As such, it is quite
> possible that the print driver (or even the application) incorporates 
> its own "RIP" so your figure:
> 
>   Application -> print-driver -> spooler -> RIP -> device driver -> device.
> 
> could look like
> 
>   Application -> print-driver/RIP -> spooler -> device driver -> device.
> 
> instead.

Certainly there are many ways of skinning the cat!

The above model resembles the GDI way of things in MSWindows.
The implication though is that the print-driver/RIP needs to
have access to details about the device, including it's
colorspace. When this is all on the same box, it's not too
hard. If the spooling is over a net, then you need a suitable
protocol if the device information is centralized, or you need
to duplicate device information on each client box. For many
printers it is desirable to feed back real time state information
(ie. what trays have paper, and what size is the paper ?).

[Diverging somewhat to explain the benefits of feedback from the
printer:]
A more advanced concept would support "logical" paper supply.
A "logical" paper is an operator defined combination of a physical
paper size and other attributes, e.g. weight, tint, letterhead, finish
etc. The printer operator would configure the available logical papers,
and the user can then select amongst them. If the printer isn't
actually loaded with that paper, the job would be held until the
operator reconfigures the printer.
A color profile would be associated with each logical paper.

Coming back to color profiles, in practice (particularly with
inkjet printers), it's not reasonable to insist on a hard coded
one to one relationship between mode combination (ie. paper type,
resolution, print modes etc.) and profiles. There is too much
of a combinatorial explosion. For example, a typical inkjet
may have a dozen paper stocks from the manufacturer, plus countless
others from 3rd party suppliers. There are very often several
resolutions and print modes (ie. dot sizes, interleave modes)
available. Multiply all this together and you start needing
several hundred different profiles to cover every combination.
[If any of you have looked at a lot of the profiles provided
  with some of the inkjets, you might notice that the profile
  coverage is patchy, and many of the profiles are duplicates.]

The best idea I came up with to tackle this issue was to use
the power of a calibration system (which partly compensates for
many of the major variables caused by resolution, dot size and
interleave modes), with a "fuzzy" profile matching scheme.
Each profile is labelled with the print parameters it was
created for (private ICC tags), and this is used in a weighted
difference sum to compute a match factor with the desired
operating mode. The profile with the best match is chosen
as a default. This would mean that a "profile not available"
type error is avoided, hidden duplication of profiles is unnecessary,
and the user gets the best possible profile available under the
circumstances. Of course they can be warned about an imperfect
match, so that they have the option (given tools) of creating
a profile for a specific paper+print mode.

Graeme Gill.