[Openicc] CUPS Color Management under Linux gets into distros

[Chris Murphy]

On Mar 2, 2011, at 3:14 AM, Cyrille Berger Skott wrote:

> On Tuesday 01 March 2011, you wrote:
>> 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 were speaking of printing, weren't we ? Krita does compensation for display 
> on a screen, provided that you have either set the profile in X11 or in 
> Krita's settings. Display a color managed picture correctly on a screen is an 
> important feature for Krita, printing (a color managed picture correctly or 
> not) on a printer is only a nice-to-have feature.

I'm glad that it's doing display compensation. That's a major plus.

But dropping metadata when producing a PDF is a kind of data loss. I don't think people would appreciate it if 500 pixels off the bottom of every image were to just go missing, and only when producing PDFs or printing. And just because they aren't aware of color fidelity data loss doesn't mean this data should be handled better.


Chris Murphy