Review Request: include KolorManager in kdegraphics

[Kai-Uwe Behrmann]

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.

> 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.

>> 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