[Openicc] Re: Hello *and* (was): LINUX, Gutenprint / CUPS / Color policies

[Graeme Gill]

Chris Murphy wrote:
> No print drivers from the major manufacturers perform color  management 
> with a particular print job containing multiple source  profiles. On 
> both platforms, this is deferred to the operating system  to manage with 
> input from the printer driver based on print dialog  settings. In-driver 
> color management is limited to black box color  management with an 
> assumed source space and destination space of some  kind, along with the 

I can't agree with your generalization there. The Colorbus RIP that
I was rather involved in (:-)), reads in PostScript from the Windows print
spooler, and does do complete color management, including multiple
sources etc., linearisation, ink limiting etc., and according to
the broad view, is simply a fancy "print driver".
The fact that most of the "out of the box" print drivers from popular
printer manufacturers don't do such a good job in handling color,
is exactly why there is a niche for third party print drivers and RIPs.
[They are also constrained by the design of the Operating System, of course.]

A lot of confusion rests with terminology. By one view of a computer
system, there are only two parts, the "O.S." and "Applications".
By this view, the operating system refers to the complete
application environment, including sub-systems such as
print spoolers, print drivers etc. etc.

A more technical view distinguishes between the core O.S.
(the kernel), and all the other application environment
sub-systems built on top of the services provided by
the kernel. In this view, there are three parts:
"Kernel", "Application Environment", "Applications".

These differences are more apparent on Open Operating systems,
where the first two elements are not from the same vendor.

Similar termonolgy differences exist in refering to "print driver".
In a particular Operating System, this term may have a very
precise meaning, and therefore imply a precise set of
functionalty. In more general discussions, a print driver
has no precicise boundaries. It is "the software that
drives the printer".

In discussing ideas for new implementations, I think it's pretty
important to separate fundamental architectural ideas from limitations
of current implementations.

A general building block approach to color (which I and others
are trying to articulate), is one in which each building block
can be as independent as possible, while still being supplied
with all relevant information to do their job. This makes it
easy to design and build each block, easy to debug each block,
and adds great flexibility in allowing blocks to be mixed and
matched.

In handling color information, what's required (I think) is
tagging of the form:

If device colorspace:
	Definition of colorspace (e.g. reference to a profile)
	Intent information, to guide subsequent color conversions.
else if device independent:
	Gamut of objects color
	Intent information, to guide subsequent color conversions.

Of course it helps the processing blocks implementer immensely,
if there is a CMM available for them to use.

A printing device generally has a requirement for conversion
to a specific, device dependent colorspace. The very purpose
of a print driver (in the general sense) is to encapsulate the
peculiarities of that printing device, so that nothing else
needs to know its details. While it's certainly possible to
allow for the distributing of this task to other elements
such as applications (and it may be a good idea to allow for
extra flexibility), fundamentally the "driver" is the only
element with direct access to all the information needed to
do the job. It knows what mode the printer is going to be in,
and what colorspace is native to the device, and (if a tagging
convention is followed), what the colorspace of the graphic
information to be printed is.

The broader "print driver" may well be composed of several,
interconnected building blocks or sub-elements (such as a RIP,
print protocol driver, printer interface hardware driver),
which (with the help of carefully designed interfaces) help
carry out the task of turning a page description format
into the raw format needed by the device. It's a matter
of design as to how formal the interfaces are between such
sub-elements, which in turn determines the feasibility and success
of allowing such sub-elements to be interchanged or "installed".

A sufficiently well designed set of components can go a long
way in supporting multiple different printers with a "table
driven" approach. Color profiles are an element of such a
table.

Graeme Gill.