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

[Hal V Engel]

On Thursday 12 May 2005 09:52 am, Chris Murphy wrote:
> On May 11, 2005, at 11:43 PM, Graeme Gill wrote:
> > It's a matter of semantics. By some views, the driver is "part of
> > the OS".
>
> It's a 3rd party "part of the OS" then.
>
> > In the tagged view of color, every element that handles color data
> > has some mechanism available to convert from the colorspace the data
> > is in, to the colorspace that processing element needs it in to do
> > its job.
> > This conversion could be handled almost transparently by other
> > OS elements, or might be quite explicit within the print driver.
> > A printer driver (in the broad sense) has a primary job of seeing
> > that the graphic information it is given, is transformed into a
> > form suitable for the printing device. Making sure (by whatever
> > underlying mechanism) that the color space is correct for the
> > printer is fundamental.
>
> A driver ensuring conversion from pixels to commands to produce
> droplets in a reasonably consistent, predictable and logical manner
> is fundamental. Colorimetric accuracy is not.
>
> 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 various ink limiting and black generation they
> choose to use for each paper type. I  haven't heard a compelling
> argument for making printer drivers more sophisticated in this
> regard. More complexity means more points for failure, and
> differences in behavior from printer to printer, and that doesn't
> help anyone. They are already complicated enough, and lacking
> sufficient documentation on Mac OS X, at least, that the CMS isn't
> getting correct information from the driver and thus the whole
> shebang is busted. Putting more dependency on successful outcomes on
> driver developers, I think, will only make the problem worse.
>
>
> Chris Murphy


I think we need to take a step back and talk about how closed systems are 
different from open systems.  So here are some major differences with respect 
to CM:

1. Most major printer manufacturers do not supply ANY drivers for their 
printers for open source systems.  The available drivers are supplied by 
third parties such as the guten-print project.  So if we decide that some 
functionality belongs in the print driver we do not have to wait for Epson or 
HP or whoever to implement those changes in their non-existant drivers.  All 
we have to do is convince the guten-print team that this is needed.

2. In the open source world we think of the OS as being the kernel, kernel 
modules and some basic low level utilities.  The total size of the binaries 
that make up the OS and related utilities is only perhaps 10 or 15 megabytes 
perhaps less. The OS does not include the spooling system, the print drivers, 
windowing systems, desktop environments, video drivers or image acquisition 
software.    These are third party software that is layered on top of the OS 
that are supported by groups that have little or nothing to do with the OS 
implementation.  This is fundamentally different from how closed source 
systems are implemented and supported.

3. The groups that are responsible for the major open source spooling system 
and print drivers are members of this list and are taking an active role in 
the activities of this list.  Also they seem to have made an implicit 
commitment to do the right thing to get these systems to properly support CM 
and are participating in this list to better understand what the right thing 
is.

4. In the open source world there are currently only a few apps that do 
application based CM and only a few that are working on or committed to 
adding CM support. 

5. Current open source print and windowing systems do not do CM at all.  So we 
are working with a nearly clean sheet of paper.

It seems to me to be useful to talk about what is wrong with the current 
closed source CM systems so that we can avoid making those same mistakes on 
our open source systems.   But I think we need to avoid projecting 
limitations that exist in the closed source world onto open systems.  We know 
that Apple does it a certain way and that the design is flawed.  The same 
thing is true for Windows.  We also have a lot better understanding now of 
how these systems are used then Apple or Microsoft did when they implemented 
their flawed designs.  Based on this greater level of understanding I 
suspect, no I am certain, that a design starting from a clean sheet of paper 
will have significant differences from what Apple and Microsoft are currently 
doing.

Chris is clearly an expert in the use of CMM.  We have at least one other 
person on this list who also has a very high level of expertise in the use of 
CMM and who works as a CM consultant.  I am also a CMM user and I consider 
myself to have a moderate level of CMM know how but I am sure that I do not 
have the depth of knowledge that Chris or Jan-Peter do.  We are very lucky to 
have these folks on board as subject matter experts.  Most on this list are 
developers.  You know the guys and gals that write the code but who may not 
be, likely are not, subject matter experts in the use of CMM.   There is an 
opportunity to pull together these two groups to produce something that goes 
way beyond any of the existing CM systems.  

As a systems analyst I have learned that you can not build a successfull 
system unless you understand what the users need or want from that system.  I 
believe that the CM systems that Apple and Microsoft implemented are flawed 
because they did not understand how these systems would or could be used.  At 
this point I don't think that we have a clear understanding of what needs to 
be done.  In fact I don't think we have a clearly documented set of user 
requirements which is the first thing that a systems analyst tries to nail 
down in the process of designing a system. 

Chris you are now sitting in front of a clean sheet of paper - How do you want 
an ideal CMM system to work?  What does an ideal CMM workflow look like and 
what data elements are needed to support that workflow?  What things would 
you like to see that would allow you to setup a CM workflow for non-expert 
users or users with no CM training at all?  What are the roles that exist in 
a CM workflow and what is needed to support those roles?  Is there an 
administrative role of some sort?  If so what is needed to support that role?  
These are just some of the questions that need to be answered.  

When designing systems one of the things that a systems analyst does is to 
"lock" the expert users and the senior programming staff in a room for a few 
days to try to map out what the user requirements for the system are.  
Durring that time the programming staff is there to listen to the users and 
to ask questions.  The idea being that the systems analyst and senior 
programmers walk out of that room with a basic understanding of what the 
users need.  I think that this list is now that room.  We have 
representatives from several projects that can be thought of as senior 
programmers and we also have several expert users of the system we are trying 
to build.   We should be trying to nail down what the high level user 
requirements are.   After we understand that we can start looking at the 
implementation details.

Hal