Review Request: include KolorManager in kdegraphics

[Matthias Klumpp]

2012/3/14 Kai-Uwe Behrmann <ku.b at gmx.de>:
> Am 14.03.12, 21:10 +0100 schrieb Thomas Zander:
>>
>> On Wednesday 14 March 2012 18.12.13 Kai-Uwe Behrmann wrote:
>>>
>>> Am 14.03.12, 17:46 +0100 schrieb Thomas Zander:
>>>> 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]
>
> CUPS is a cross platform solution. It works with colour management on osX
> fine. IMO that recommendation on Debian has to do with colord in Gnome and
> that colord needs compiled in support inside CUPS. No more no less.
No. Cups uses the Color Management system provided by the OS. On
MacOS-X it uses ColorSync, for example. Cups itself has a patch
included which makes it use colord DBus-API to talk to colord. That's
the reason for CUPS recommending colord on Debian.

>> Notice that colord allows components to use it without linking it in at
>> startup using the dbus interface for instance.
> That is non relevant to the fact, that CUPS vendor colour management works
> since years and without colord.
It does - on MacOS-X, because it uses ColorSync there :P

Regards,
   Matthias

>>> 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%
>
>
> I still do not see merit in the user session in CUPS server hook concept.
> I would really like to understand why it is a good design, but no one gave
> so far a satisfying answere on OpenICC. Maybe it can be found here?
>
> Look at the details. colord is called inside CUPS server. CUPS servers can
> be remote without any DBus connection, which colord relies upon. The CUPS
> server is, well, a server, not client software. It takes print jobs through
> a well defined communication path after lots of security checks. Now colord
> breaks these security check on a local host and says to CUPS to use a
> certain ICC profiles. colord needs special rights to take the user
> configuration from a central DB. As long as the actual user is printing a
> actual job with a actual colord profile it is fine. Laptop and one person
> systems might work this way. But imagine that now on a multi user system. A
> remote print jobs comes in. CUPS prints that with the profile of the local
> user. These users are likely not the same person or account. That is why the
> Oyranos project did reject the offer to place a similiar Oyranos hook inside
> CUPS and why it is criticised inside OpenICC without sufficient answeres.
>
> The colord printing configuration architecture fits maybe to a one person
> system like Android, provided that it uses a direct connection to the actual
> printing device. Ironically Android does not allow for DBus.
>
>
>> without support in the individual components.  If Cups needs to be patched
>> to
>> support a new feature, that sounds sane to me.
>
>
> There is a half new feature. The other half cuts into existing well defined
> behaviour. Colour Management for vendor configured profiles resides inside
> CUPS since quite some years. The rastertoprinter filters do colour
> correction through the respective poppler and ghostscript filters. The CUPS
> CMS configures that fine. Again CUPS does not need colord to do robust CM.
> It looses robustnes through colord introduced ambiguity. See above.
>
>
>> 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 :)
>
>
> That sentence covers only part of the conditions needed to judge. See above.
>
>
>>> 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. :-)
>
>
> My impression is, here are made assumptions that are based on abstract
> ideas, which do only in parts fit to the situation. That is irritating.
>
>
>> 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.
>
>
> You are broadly speculating. May I ask for what reason?
>
>
>> 1) http://packages.debian.org/wheezy/cups
>> --
>> Thomas Zander
>>
>
> regards
> Kai-Uwe Behrmann
> --
> http://www.oyranos.org