Re: [Openicc] colord 0.1.0 released!

[Chris Murphy <lists colorremedies com>]

On Jan 17, 2011, at 7:25 AM, Kai-Uwe Behrmann wrote:
> 
> To summarize my view on the current colord approach:
> it tries to substitute, what I expected CUPS solves with own means. It copies a knowingly problematic solution from an other OS, and introduces
> the many of these problems as well on Linux.

Perhaps I'm missing something, but I do not get this impression. To achieve what Apple has achieved first requires an incredibly specific and immutable ideology with respect to /DeviceRGB (i.e. untagged data) needing to be totally banned to the degree that if it is found, it is stripped away and data is instead tagged as sRGB (on Mac OS X 10.6, and Generic RGB on 10.5 and older).

Further, to achieve CMS off at a system level, requires an opt-out method of color management, meaning the application must send a written invitation to ColorSync to disable it, and the written invitation itself can be questioned by ColorSync. And further the SPI Apple provides to do this allows PDF print spool files with conflicting source and destination profiles, ensuring conversions will happen even though the entire purpose of the SPI is to disable conversions.

It's such a high order of irrationality that it's a challenge to articulate it without resorting to ad hominem attacks. I cannot imagine that wholesale stripping of metadata and replacing it with other metadata, without end users being consulted, is acceptable in a Linux or open software context. Let alone creating SPIs. Let alone APIs that would pass community muster that encourages sabotage of the workflow. So anyway, I don't see a correlation at the moment, but rather a clear sensitivity to avoid Apple's mistakes.


Chris Murphy