[Openicc] Assuring that all CUPS filter chains under Linux accept ICC profiles

Kai-Uwe Behrmann ku.b at gmx.de
Thu Feb 2 03:10:53 PST 2012


The following comparision shall clearify my standpoint towards the 
colord hook in CUPS. Comments on the points made below are appreciated.

Am 29.01.12, 20:54 +0100 schrieb Kai-Uwe Behrmann:
> Am 29.01.12, 19:12 +0100 schrieb Till Kamppeter:
>> Now we need to check whether we can really use ICC profiles with all 
>> printers and drivers under Linux.
>> 
>> Thanks to the great work of Richard Hughes CUPS and at least the 
>> Ghostscript rendering filter gstoraster (PDF or PostScript to CUPS Raster) 
>> accept both user-assigned ICC profiles through colord and 
>> print-queue-assigned ICC

If users shall be enabled to use available resources efficiently and 
effectively for colour management, they must remain in control of the 
selection of colour profiles and belonging settings.

Let me compare the actual discussed possible two aproaches to user 
configured print profiles.

1. colord user selectable per session print profile
   (as patched into CUPS by RedHat team members)
   - side stepping CUPS API
   - needs permanent root access (might be fixed now by security team
     members)
   - non transparent to applications through the document or the CUPS API
   - potentially affects print job of other users as selection is time
     based
   - thus it may override other profiles in a more or less undefined way
   - not network transparent (which is only a missed feature)
   - three CUPS identifiers are non sufficient for complete calibration
     state control in PPDs
   - all these concerns from the colour community are long known

2. user configurable per print-queue-assigned profile
   (as investigated by Edmund Ronald)
   + conformant with CUPS PPD configuration (which will remain available
     for some time)
   - needs one time root access to create and install a new PPD
   + queue is available to all users
   + queue is network transparent
   + profile selection is transparent to applications through CUPS API
   + clear per job assignment of profile configuration
   +- need further work and adaption to IPP, which can be hidden in APIs of
      a CMS
   + complete calibration state control by locked colour attributes in PPD


Both paths allow in different ways per user selectable profiles for print 
colour correction, but not on the same level.
The intransparency and side effects of the colord hook in CUPS make it 
dangerous to manage colour on the Linux desktop. Thus it can cause a lot 
of cost and time to users and other endities.
The print-queue-assigned profile offers a chance to fullfil the promise 
given in the term colour management. It works in prectical and standard 
way.


kind regards
Kai-Uwe Behrmann
-- 
www.openicc.info


Disclaimer: As OpenICC member I have no preference over one or the other 
or any further solution, provided it supports the above objectives of 
colour management on the open source Linux platform.




More information about the openicc mailing list