[Openicc] CUPS Color Management under Linux gets into distros

[Chris Murphy]

On Feb 28, 2011, at 7:22 AM, Cyrille Berger Skott wrote:
> 
> 
> It is worth to note that for Krita, we do not consider printing as part of our 
> important features. IE, we consider that the artists job stops in Krita at 
> creating the image. He can print it on his 30€ printer, but if the user is 
> running a shop with 30000€ printers, he should use other software to print the 
> image (after drawing it with Krita, of course ;P ). This is why Qt not 
> supporting the color profile in PDF, and having to convert to sRGB 8bits, is 
> not considered a critical issue for Krita. Of course, if at a latter stage, 
> the API allows better support for color profiled printing, we will make sure 
> that Krita makes the best of them.


If Krita does not do display compensation (does it?), then color itself is not a part of its important features either. Simply tagging the data as sRGB, or some other color space, is completely useless if display compensation isn't occurring.

We really need a singular solution to encourage other applications to more easily opt-in to display compensation, rather than expecting everyone to roll their own solution for each application. Perhaps at some future date, the dust will settle with respect to window services, and it will be possible to wedge in display compensation for all applications unless they expressly opt out. But in the mean time, a display compensation "service" at a system level needs to be something they can subscribe to.

Chris Murphy