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

[Graeme Gill]

Chris Murphy wrote:
> 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.

You're right of course, it does get complicated. There's no
point in tackling something so complicated that it never gets
finished. On the other hand, there's no point in architecting
something so limited, that it's limitations rapidly become a handicap.

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

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.

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.

It's far easier from an implementation point of view just to
dump on the user all the implementation details of the device
(What paper type, what resolution, what printing mode etc.),
since this will work, and gives the user an ability to fully
utilize the printers capabilities (if they can understand
how to do it !)

Graeme Gill.