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

[Chris Murphy]

On May 12, 2005, at 9:56 PM, Graeme Gill wrote:

> 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

OK, let me rephrase. Let's scratch "major" and replace it with 
"printer". What I'm referring to are the manufacturer supplied printer 
driver for Mac OS and Windows. I'm not talking about 3rd party 
drivers/RIPs.

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

That is a good explanation, and a compelling one for making print 
drivers more self-sufficient. If certain "services" being available on 
a particular machine cannot be guaranteed, then there's going to be a 
certain redundancy by necessity.

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

As soon as you walk away from a printer driver assuming a normalized 
workflow (i.e., a single source space either assumed or explicitly 
tagged for the print job), it makes this a lot more complicated. A lot. 
Especially if we start talking about prepress requirements.

I think it's easier to start with perhaps a couple of paths to the 
print driver which maybe are too simple, but can be developed in the 
timeline for Gutenprint 5.2. Anything that cannot be done that an 
application needs to do, will need to be done by the application (such 
as normalizing and tagging that data). Eventually, it could make sense 
for the printer driver to have other paths, including one to receive 
print jobs containing multiple source profiles and also distinguishing 
between different kinds of objects - some thing ought not be color 
managed exactly because some objects are things more than they are 
colors (like black text or red text going to a press). Adding this 
support doesn't mean extricating other paths to the print driver - in 
fact those  paths will still be necessary for legacy support, as well 
as for applications that merely have simpler requirements.

Rather than the print driver having to manage print jobs with multiple 
source profiles right off the bat, I'd rather see the print driver 
abstract away from the end user having to select output device profiles 
everytime the user prints - and go with a profile+device association 
mechanism. Eventually we may have printers that determine what media is 
loaded already (HP has had this technology in some of their printers 
for years), so the end user won't need to select a media type setting, 
just a resolution setting perhaps. A well implemented color managed 
printer driver would grab this information from the printer and the 
print dialog box, and select the correct output device profile through 
previous association.

And even that may be pretty complex because it implies some kind of 
application, independent of the printer driver, that would be used for 
making these associations.


Chris Murphy
Color Remedies (TM)
www.colorremedies.com/realworldcolor
---------------------------------------------------------
Co-author "Real World Color Management, 2nd Ed"
Published by PeachPit Press (ISBN 0-321-26722-2)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 4116 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/openicc/attachments/20050512/d3718bdc/attachment.bin