[Openicc] printing GUI vs. printerdriver, LINUX colorinfrastructure

[Kai-Uwe Behrmann]

Am 21.04.05, 18:44 +1000 schrieb 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.)

Hmm  thats a modus for standard users. The last is shurely prefered for 
custom profiles.
 
> 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.

My impression is that a working system without the need of technical user 
intervention tends to a invisible hard to "diagnose" system. My thought 
was to represent a technical detail in an easy understoodable manner.
My impression with linux is, projects like kde and gnome tend to convince 
the user with a lot of solutions which become more and more 
internal technically. 
The transparency for average users gets quickly lost. Let me ask 
rethorically: who reads html style xml-configurations? No one, it is 
simply intended to programmers. For a user it is all about strange.

The same will be for a CMS. Eighter we go a technical way and customise 
it. This means we call things by a technical close related name (hopefully 
clear and recogniseable names) or go the way like many other OS and hide 
as much as possible behind convenient buttons and names, resulting in a 
hidden windows/osX style configuration.

I can follow you with the first intention of a CMS that just works and is 
very easy to handle or better needs no handling. I would like to see it 
the technical way, having all that pleasing buttons by hand for the 
experts.
On osX all use that nice Aqua gui for print settings. No one has the idea 
to call http://localhost:631/ to watch the CUPS page. But it is nice for 
experts to see the internals.
IMHO we need first a functional layer with the vision of future usage 
behaviour, and can later set a convenient GUI on top. So I think now you 
are speaking of the top GUI layer which is able to hide all CMS issues 
from an user. Ok thats fine to consider as a design goal.

back to the toppic
The CMS should support both user intervention behaviour. The GUI is second 
stage.

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

Ok that should be implemented as a standard option as well.

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

Agreed


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