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

[Kai-Uwe Behrmann]

Am 29.01.12, 19:12 +0100 schrieb Till Kamppeter:
> I have done the first release of the new OpenPrinting CUPS Filters package on 
> OpenPrinting (see new item on http://www.openprinting.org/), giving an 
> upstream home to the new CUPS filters for the PDF-based printing workflow and 
> also for the filters which will get dropped by CUPS from version 1.6.0 on.
>
> 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

I would not call that a great work of Richard Hughes and his Fedora 
partner. These few lines of code form a hack on the level of a toy 
API.
Colour management is something different. And I understand you 
want colour management to work inside the printing path. Management 
includes typical basic measures to ensure proper operation.
Due to known design reasons, there is no checking that the colord hooked 
profile will be used for the desired job of the user. 
It is not secured that calibration matches profile selection beside of 
three profile selectors, which are repeatedly mentioned as non sufficient.
For instance a user can change gamma and brightness inside a print 
dialog and the calibration state including the profile selection is 
completely invalid.
These bugs are imminent characteristics of the colord in CUPS user profile 
selection path. I think it is extremely important to point these flaws out 
and point to the continued unwillingness of its authors to fix it.
(I read today that others now fix bugs in colord like the root right 
requirement. This knowingly bugged the openSUSE security team and they 
took action on that.)
The colord hack does not meet production standards for printing and will 
waste the valuable time of our users, while they try to figure out 
where the resulting bugs come from.

> profiles through the *cupsiccprofile keyword.

There is thank due to those people who introduced or reworked 
ICC colour management in the available rasterisers and connected the 
cupsICCprofile mechanism to these rasterisers. They did the core work and 
we know it took some effort to get that done. Again thanks for that work. 
It is greatly appreciated.

> This will at least make filter chains like these color-managed:
>
> [PDF]->pdftopdf->gstoraster(GS)->rasterto...->[printer]
>
> Now there are also these chains:
>
> [PDF]->pdftopdf->pdftoraster(Poppler)->rasterto...->[printer]
> [PDF]->pdftopdf->pdftops(GS)->[PostScript printer]
> [PDF]->pdftopdf->pdftops(Poppler)->[PostScript printer]
> [PDF]->pdftopdf->foomatic-rip(GS)->[printer]
> [PDF]->pdftopdf->foomatic-rip(Poppler)->[printer]
> [PDF]->pdftopdf->pdftops(GS)->ps-based-driver->[printer[
> [PDF]->pdftopdf->pdftops(Poppler)->ps-based-driver->[printer[
> [PDF]->pdftopdf->[PDF printer]
> [PDF]->pdftopdf->gstopxl->[PCL-XL printer]
> [PDF]->pdftopdf->pdftoopvp(Poppler)->[printer]
> [PDF]->pdftopdf->pdftoijs(Poppler)->[printer]
>
> Assuming CUPS, cups-filters, ghostscript, and Foomatic are the current VCS 
> states, which of these chains do already support color management, and which 
> of the two forms (*cupsiccprofile for queue-based ICC and colord for 
> user-supplied ICC)?

I strongly suggest to remove the colord manipulation hook from CUPS as it 
forms a non fixable bug and is a danger for colour managed printing on the
Linux platform.

We should work on alternative and working paths. The per media print queue 
is far more workable in short term. It works for user profiles and is 
highly integrated into the original CUPS way of profile selection.

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