[Openicc] printing GUI vs. printerdriver, LINUX colorinfrastructure

[Graeme Gill]

Kai-Uwe Behrmann wrote:
> Interessting. My second thought about describing different intended 
> options for one profile was to use standard PPD files. The PPD file, a 
> certain profile is tagged with, can contain all options and make the 
> dangerous one static (remove alternatives). With your approach for 
> instance print resolution would become variable for the intended dpi, 
> while for instance dithering would be static with only one value - say 
> "Ordered". An other profile could cover the remainder of dpi settings for 
> ordered dithering

My impression was that most print systems don't allow easy selection between
PPD's. There is usually one PPD for a type of printer. Of course if you are machine
generating the PPDs, and have several logical printers, you might be able to
configure different PPDs for each logical printer (but then such color
setups can be part of the logical printer definition rather than being in
the PPD).

My thought was that profile selection should be as invisible as possible.
If the user has a preference for a particular printing mode, then
the color should (as far as possible) automatically accommodate
that printing mode. (Of course it might be desirable to be able to
reverse that priority, ie. pick a profile and make the printer mode
conform to what it is set up to.)

PPD's are also rather a limited mechanism for controlling a printer,
since they have a limited ability to customize, and can't accommodate
feedback as to the state of a printer that lies at the other end of a
spooler queue (At least not without heroic efforts, like installing a local
  user agent that communicates with the printer, re-writes the PPD
  whenever anything changes, and then triggers a local print system
  PPD re-registration.)
In many ways I thing PPDs have reached their use by date. There
doesn't seem much on offer to replace them though.

> Usually the user wants to set to print with or without profile.

I don't really agree with that. Usually the user wants the color to come
out right. Fundamentally they don't want to know the mechanisms used
to provide the right color (only techies are fascinated with this,
or something is not working, and the knobs and buttons need to
be changed to diagnose, correct or work around the problem.)
Even for calibration or profiling, it's a clumsy way of doing
things to demand that the user manually set "no profile" before
running a test chart out.

The whole idea of a CMS, is that it should make things easier and
more foolproof. Provide profiles for each device, and label the
colorspace of every color representation, and things should
"just work". The biggest technical obstacles to things just working
at the moment, is the lack of appropriate and "rich" intent labelling,
and the lack of a good ability to honour such intent with smart
gamut mapping. All this pales into insignificance compare to
the practical problem that few applications and systems conform to this idea,
many work poorly, and most are unnecessarily complicated and hard to understand.
The closest thing conforming to the ideal is Apples OSX, but it still has
various problems, not the least being that it's mechanisms are so hidden,
that it's very difficult to diagnose and solve the problems that do come up.

> The CMS would provide a set of available options(extracted from profiles) 
> for the selected print queue (select by printer device).
> Then a GUI wants to present proudly the many options which are available. 
> This is a dangerous point during interaction. Following the above dpi 
> example, one profile may cover Ordered:360+720dpi the next 
> Ordered:1440dpi. An thierd profile covers Eventone:2880dpi . Now what to 
> present to the user? She will quickly discover that selecting Ordered 
> limits the available dpi selections to 1440dpi and Eventone forces 2880dpi 
> . Usual a user thinks about options in a sense of linear availability. The 
> fuzzy approach would change this experience with options "from case to 
> case".

I think you are talking about the reverse priority. My suggestion was that there be
free selection of the various modes, and the back end color system
heuristically chooses what is likely to be the most appropriate profile,
perhaps notifying the user if it is not a perfect match. Displaying
the actual setup that the profile is for, might provide a hint as
to how to change the modes to better match that particular profile.

> A solution could be to design a 2 stage selection. First select a profile, 
> which allready fits in the device/print driver mosaic. Then watch the 
> available optins and fine tune the setting or leave it by defaults.
> 
> Thats not entyrely satisfactory. A GUI wants to present categories like
> [draft] [quality] [photo quality].
> I am doubt that such categories can been tagged to a profile in a 
> consistent way.

But those user level selections are going to be translated into
printer specific selections at some point in the processing,
and it is those specifics which should be recorded in the profile
and matched to.

> A difficulty for a CMS is to filter out which profile from 
> a set of profiles is able to fit in a given options set (PPD parsing).
> I am uncertain where PPD parsing would best fit in (driver versus CMS).

I don't see this as a huge problem. It's just a mater of turning
category mis-match into appropriate numbers, weighting them and
summing them. A bit of trial an error would soon refine such a heuristic.

Graeme Gill.