Review Request: include KolorManager in kdegraphics

[Daniel Nicoletti]

> 2012/3/14 Kai-Uwe Behrmann <ku.b at gmx.de>:
> 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.
This sentence is hard to read but Recommends in Debian means recommends,
it is not required to run, so no there is no linking, no link by CUPS to colord and
no link by colord to CUPS. All DBus magic.

>> 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 is indeed relevant because now we have a central place to configure it.

>>> 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
There is no security break, sorry, I know CUPS, CUPS is the one calling
an extra thing not the other way.

I'm not sure if this is what happens currently so I'm going to say what I would do:
First regular users don't touch /etc/cups/client.conf - The file that makes
your cups calls go away. They don't need that to talk to remote printers
CUPS is smart enough to talk to another CUPS over the network.
So a process that uses less than 1MB can just be installed on each Linux
machine (as is the case today).
If CUPS is locally installed this means it can just send the job color corrected!
Plain simple...

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

I see no irony we do not target Android instead our users which lack CM.