[Openicc] colord Printing Plans

[Kai-Uwe Behrmann]

Am 24.02.11, 22:34 -0000 schrieb Richard Hughes:
> On 24 February 2011 21:55, Kai-Uwe Behrmann <ku.b at gmx.de> wrote:
>> This is wishful thinking. The session and a colour management policy are
>> separate concepts. The colour handling inside a session is bound to several
>> rules, which are independent to any policy agent.
>
> And you want to expose those concepts to the user? Users just want

A real policy would follow standards.

> things to work. The only "concept" the use has is that they want to
> make the printer squirt the right colour ink out of the jets onto the
> paper.

Agreed for this over all goal.

>> What would be if an other CMS would start playing this game too. We would end with
>> three four five ways to configure the CUPS server side profile. All in
>> different UIs and systems. Thats chaos.
>
> I'm not suggesting there be more than one CMS installed on a system.

Then stop colord in CUPS. It is a second CMS in the server side print 
path.

> No user ever should have to choose between CMS's or even install such

That would be great. But again we have already three colour management 
systems in open source. All three are distributed in e.g. Fedora. So we 
need an other path to reach that goal or will easily fail.

> a random thing on the system. I see a CMS as an integrated layer of
> abstract glue rather than as a replaceable subsystem.

For parts there the CMS has control over, this might be true. E.g. mutter 
can use colord, while compiz can use Oyranos. Funny policy enforcement.

> In Fedora 15 we'll be installing colord by default and GNOME 3.2 will
> require colord to function. If you want to do all the integration work
> to make oyranos work in place of colord, that's fine with me, but I'm
> concentrating on making colord just work out of the box with upstream
> ghostscript and cups. People have been talking about a perfect CMS

No, you make ghostscript and cups use colord, without good reason 
as we pointed out.

> architecture for decades now, and it's time we ship something that
> actually works.

In these "decades" we discussed quite a few things. Some of them recently. 
How about get that work into the colord architecture? colord in CUPS 
appears to me as non helpful. This special design decission of placing 
colord in CUPS is weak and exposes a huge dead weight on the future 
development process. Delaying the open answers to later, while we had 
already found other answers to the very questions is a mystery to me. Your 
continued ignorance can not convince.
You get answeres over answers and come always back to the same fruitless 
conclusions.

For a hasty sooner distribution of colord you try to encumber Gnome and 
Linux with a not so nice mortgage. Its unhealthy cosmetic.

Yes, its time to ship a colour managed printing system. Till has announced 
a complete vendor side colour managed printing system here on list. It 
consists of CUPS, Ghostscript/Poppler, a pdftoraster filter and hopefully 
ICC profiles, which will be configured in the printer drivers PPDs. Not 
perfect for all cases, but a start. If you want a annoucement, that is the 
right one. Forward it to the Fedora marketing team if you like. This 
concept does not need any colord daemon code to work. This solution is the 
one, which will help the most users.

> It would be helpful if you could even consider implementing the same
> DBus interface in oyranos we're using in colord (I'm even happy to
> change API if needed), and then you'd get all the integration work
> done for free.

colord uses the three ICC profile modifiers for cupsICCprofile. This was 
regarded as non sufficient for user configured ICC profiles. Thus colord 
can badly convince.
Otherwise, CMS's agreeing about some configuration exchange path would be 
good.


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