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

[Hal V Engel]

On Thursday 12 May 2005 10:15 pm, Graeme Gill wrote:
> Maybe it's my background, but I tend to regard this as part of the
> "printer operator" interface. Conceptually there is a separate
> task involved with keeping a printer in operating condition,
> configuring it to handle jobs heading in its direction, and
> keep the connected computer in sync with the printer. This is
> a technical maintenance task involving how the print driver
> system is configured.
>
> In a really large organization, this might be someone's job.
>
> In a single user computer, one person has many hats (whether
> they realize it or not).
>
> Some current systems tend to merge and mix this task with the
> application printing interface. This is kind of understandable
> for a single user system, but I wonder if it is really a good
> idea to confuse these roles.

I think that it would be good to separate these roles even on "single user" 
systems.  Single user systems are seldom used by one user.  In most cases 
there will be one or more users with a higher levels of expertise and other 
users who need support to use the computer to its potential.  

My computer is an example.  I have setup a fairly good CM workflow with custom 
profiles for all of the devices on Windows.  Using this is not simple but 
since I set it up I have no problems getting the results I want.  My stepson 
with some training is also able to use the CM workflow but can get confused 
if I make changes.  My wife however wants things to be simple but would also 
like to be able to get the same results I can get.  But she finds using a 
manual CM workflow confusing and burdensome.   In addition some of the 
applications that she uses are color management dumb but would also benefit 
from a basic (assumed) sRGB to (custom profiled) device color space printing 
workflow.  But there is no way in Windows to set up the printing process to 
correctly handle this situation.

If the "printer operator" (I would call this the printer administrator role) 
role were cleanly implemented there would be a way for me to setup color 
managed print queues or logical printers that make it simple for users, even 
with little or no training,  to do the right thing and get very good results.  
This of course requires that at least one user on the system have some 
expertise in setting up a CM workflow but that is a separate issue.  But it 
should be possible for this to happen and on current systems it is not 
supported.   This should not be difficult to implement and we have allready 
talked about ways to do this.

This also helps to deal with the mode/profile explosion issue.  A correctly 
administered color managed printer will only have a few valid modes/media the 
end users can select and the administrator would be responsible for making 
sure that each has the correct profile and is correctly configured.  Again 
getting back to my computer as an example.  I typically have 4 to 6 sets of 
printer mode/media/profile combinations at any given time.    There is no 
reason for me to be concerned about other modes or media because I don't use 
any others.  I suspect that this is fairly typical for most "single user" 
systems although many might use even fewer combinations.  Although the number 
of combinations might be different, even in larger organizations I suspect 
that there would tend to be a limited number of these combinations if the 
system allowed the printer(s) to be administered correctly.  

>
> Selecting a device profile should not be part of a normal
> application printing interface. It is part of the printer
> operation interface. Selecting intent is the ideal way of
> abstracting things at that level. The printer driver
> then implements the requested intent with whatever
> means it has available (which may involve the "print operator"
> reconfiguring things.) Creating this is hard.

In fact I would so far as to say that when users have to use application based 
CM to implement CM workflows it is an indication that the underlaying systems 
are broken (Windows or Mac) or do not have CM support at all (*nix systems).  

Hal