Review Request: include KolorManager in kdegraphics

[Kai-Uwe Behrmann]

Am 14.03.12, 21:29 +0100 schrieb Alexander Neundorf:
> On Wednesday 14 March 2012, Thomas Zander wrote:
>> On Wednesday 14 March 2012 18.12.13 Kai-Uwe Behrmann wrote:
>>> Am 14.03.12, 17:46 +0100 schrieb Thomas Zander:
>>>> On Wednesday 14 March 2012 16.39.00 Boudewijn Rempt wrote:
>>>>>> Colord - just to mention that - is also not a GNOME project, it's a
>>>>>> FreeDesktop project. (Doesn't mean it's "standard", but does mean
>>>>>> that it's not GNOME)
>>>>>
>>>>> Well, no, having something on freedesktop.org doesn't mean it's not a
>>>>> gnome project;
>>>>
>>>> Little semantic confusion here :)
>>>> He said it *IS*  a freedesktop project.  Which means it is not a gnome
>>>> project, which seems to me to be true.
>>>
>>> It was developed specifically for Gnome Color Manager and then turned
>>> into a Glib depending library. So it bears all the specifics in it's
>>> concept.
>>
>> Notice I still maintain that we should judge a solution on merit, not on
>> who pushes it.
>>
>>>> That said; Cups also depends on colord. And IMO that has a bigger
>>>> impact than the gnome components that pull it in.
>>>
>>> colord print CM:
>>> CUPS does not depend in any way on colord.
>>
>> This opinion seems to conflict with the facts stated by others.  Debian for
>> instance has 'rec' (recommend) colord for cups.[1]
>> Notice that colord allows components to use it without linking it in at
>> startup using the dbus interface for instance.
>>
>>> But colord depends on CUPS to
>>> support it's concept of placing colord's session centric configuration
>>> into each job on server side.
>>
>> Which makes total technical sense. No color management system will work
>> 100% without support in the individual components.  If Cups needs to be
>> patched to support a new feature, that sounds sane to me.
>> Does it not make more sense to have color management support in cups than
>> cups support in the color management software? It certainly does to me :)
>>
>>> It does not scale well and will likely be difficult to maintain.
>>
>> As someone that is also a software developer, I disagree, with the reasons
>> I wrote above. :-)
>>
>> Bottom line for me really is that a project that has been around for a year
>> has managed to grow fast and get accepted widely.
>> Some may argue thats because of political issues, but in the end thats not
>> really relevant. The end result is still 'market' acceptance.
>>
>> As mentioned before, accepting kolormanager in kdegraphics is kind of a
>> "no" to colord. And I think thats would be cutting our own fingers.
>
> The wiki page somebody pointed to mentioned that colord is linux-only, while
> oyranos also works on Windows and OSX.
>
> If we chose colord, how does our solution for Windows and OSX look like ?
> Does kolormanager work under Windows and OSX ?

The printing concept, which we discussed in OpenICC and which we are 
intessted to introduce into Oyranos / KolorManager are design to be cross 
platform. We think that is important as we work daily in heterogenous 
environments. So we need to rely on
A) CUPS doing the right thing in the right place. And CUP's own CM appears
    fine. We can adapt our behaviour to use it for vendor and in parts for
    user configured profiles.
B) or we rely on standards for print job transportation. PDF is choosen by
    Linux as print format. PDF/X-3 is a international standard providing
    print profile embedding. That is used by osX as well. And let me
    speculate for good reasons. It is cross platform.

> Alex

kind regards
Kai-Uwe
-- 
http://www.oyranos.org