[Openicc] Assigning icc profiles to driver settings

[Kai-Uwe Behrmann]

Am 18.01.11, 17:26 +0100 schrieb Jan-Peter Homann:
> During the discussion started with colord, one important topic is the 
> association of an icc profile to a printer driver setting.
> 
> Currently, it seems to me, that we have following possibilities:
>
> 1) PPD colour keywords:
> The PPD for a given printer must be able, to describe all color relevant 
> driver settings with all parameters (incl. low level driver settings if 
> necessary)
> an ICC profile will be assigned to a proper parametrized PPD and the PPD will 
> completely set up the color options in the printer driver.

Oyranos has this implemented as a configuration backend. A public 
interface is still missed, but I expect the over all scheme to work 
similiar to Xorg. That is, install a ICC profile prepared with device 
settings in the meta tag and all user of the actual system see the 
according profiles associated to the according device. (Driver settings 
are handled in windowing environments typical by the vcgt tag.) That 
happens already completely without user interaction, except of installing 
the profile.

> 2) Driver settings implemented as metadata-information into the ICC-profile
> Like with the PPD-workflow, all color relebant printer driver settings are 
> stored as metadata into the ICC-profile. The printer driver must be able to 
> extract this information from the ICC profile and will be completely setup by 
> the ICC-profile itself.

I had a ICC tag proposal some time ago to embed a driver information blob. 
But I think, putting the energy into the 'meta' tag is much more straight 
forward. Well, sizes could be different. But thats maybe not an issue.

> 3) serialized driver settings
> The driver settings are able to be serialized (which optimally able to be 
> exported and imported)
> The ICC-profile will be associated with the serial ID of the driver setting.

In my findings in Oyranos, I moved away from a ID approach. That approach 
has much problems with, what the colour community tries to achieve in this 
discussion.
I think we need better implicite colour management, see my annotation 
above how Oyranos handles this extremenly well for Xorg.

The other point is we need flexibility. Once the profile changes the ID 
breaks and things are lost. During the gsoc projects we learned in the 
Oyranos project that the cost to implement a full featured solution is 
well worth the investment. Currently Oyranos is able to base all colour 
devices on the same relyable principles. Its flexible to scale for many 
use cases like vendor and user side setups. Its unified and thus easier 
maintainable. The precondition are meta informations coming from the 
drivers and devices. The Oyranos has spent time to deliver a patch to the 
SANE project. For CUPS is the ColorKeyWords PPD attribute intented for the 
same purpose.

> It would be interesting to know, which of these ways are preferred by the 
> community.

I much prefere the PPD to meta tag serialisation combined with PPD 
ColorKeyWords tagging of colour relevance for attributes.

If a driver needs more informations, like Robart has repeatedly stated, 
then I would recommend storing these informations along side the meta 
tag by extenting its interpretation. Thus it fits very nice into the above 
outlined scheme. The meta tag has displayable and data sections separatly.
Thus embeding should not be a problem usability wise.

> Best regards
> Jan-Peter


kind regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org