[Openicc] CUPS Color Management under Linux... (what is to do ?)

[Kai-Uwe Behrmann]

Am 11.02.11, 15:39 -0700 schrieb Chris Murphy:
> On Feb 11, 2011, at 6:39 AM, Leonard Rosenthol wrote:
>> On Fri, Feb 11, 2011 at 2:05 AM, Kai-Uwe Behrmann <ku.b at gmx.de> wrote:
>> Yes, in that order. Any following PDF processor can add a new OutputIntent but can not replace a existing OutputIntent. Only one OutputIntent is allowed per PDF, according to the PDF spec.
>>
>>
>> Actually, PDF supports an array of OutputIntents - but no one has ever used more than one.
>
> Could come in handy to enable proofing at a system level. But still 
> guys, I think we need to keep this implementation constrained and 
> realistic, not overly complicated. There's enough going on as it is, and 
> still some pretty basic considerations need to be agreed upon. Basic 
> considerations about system architecture, library dependencies, 
> databases, etc., that I know nothing about.

The best we can do, is to adhere to the PDF spec and discuss eventual 
cirumventions of shortcommings in that spec. The single OutputIntent 
allows us to provide a pass through mode for calibration and early colour 
binding, e.g. for simulation/proofing.

I think its realistic not to assume that the first release will support 
already the OutputIntent. But we really want it once the vendor profiles 
come in effect through pdftoraster. Its needed for a relyable opt out and 
PDF spec compliance.

> I think it's fine to think about a 1.0, 2.0 and 3.0 version so that your 
> 1.0 implementation doesn't box you into an impossible rewrite when it 
> comes to 2.0 and 3.0. But really, unlike many things, there is an "end 
> in sight" for color management implementation. But the biggest 
> impediment is getting agreement about components. If everyone starts 
> making their own implementation, then it will be yet another fractured 
> color management system that won't work very well except with very 
> specific distributions. I don't think that's very interesting. I think 
> fixing the problems most people have is interesting.

Code sharing was rejeted. I am especially sorry about that. But 
preferences differ, so we have to live with that. I think adhering to 
existing specifications and creating new recommendations if 
interoperatibility is needed is the way to go. These recommendations 
should be as simple as possible to support at least a flexible and 
extensible core of functionality.


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

PS: greetings to Edmund