[Openicc] printing GUI vs. printerdriver, LINUX colorinfrastructure

[Kai-Uwe Behrmann]

Am 21.04.05, 16:13 +1000 schrieb Graeme Gill:

> Kai-Uwe Behrmann wrote:
> > So you suggest to have all the profiles on bord? and select the best
> > matching by the desired print options or
> > 
> > do you suggest to average calibrations to get one profile for comparable
> > settings (for instance include all print resolutions into one profile)?
> 
> I was thinking that whoever creates provided profiles would normally
> create them for the most useful or commonly used papers and modes,
> and let the matching system cope with lesser used modes.
> 
> Experience indicates that often the dot gain for all except the highest
> 1 or 2 dpi are going to be similar enough that a calibration system
> would cover the difference. In such a situation one might create only
> 2 or 3 profiles of a particular paper/mode combination to cover
> all possible dpi, and expect to get reasonably acceptable results.
> Similar compromises may be possible with some of the different
> paper stocks.

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

Usually the user wants to set  to print with or without profile.
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".
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.

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

Sorry if I go so quickly into details. I thought several times about this 
scenario.


> Of course home users don't often have the necessary tools to do
> calibration (although a scanner might be pressed into service in this
> regard, if there was a way of calibrating the scanner! This is a hard
> problem to solve, since the spectral response of a scanner can be
> quite different to an instrument, and the spectral characteristics of
> a widely available standard like an IT8.7/2 is likely to be quite
> different to an inkjet or laser printer).

I expect it depends on prices.

regards
Kai-Uwe Behrmann
                                + development for color management 
                                + imaging / panoramas
                                + email: ku.b at gmx.de
                                + http://www.behrmann.name