Review Request: include KolorManager in kdegraphics

[Kai-Uwe Behrmann]

Am 14.03.12, 14:29 -0700 schrieb Daniel Nicoletti:
> 2012/3/14 Kai-Uwe Behrmann <ku.b at gmx.de>:

> It is indeed relevant because now we have a central place to configure it.

And users need to manage and error check everything themself. I would not 
use that in a professional environment, where time counts.

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

That is wrong. CUPS is patched to call colord. CUPS itself does not use or 
need a extra thing.

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

You checked that? The first respond from the colord author, which I have 
read, was that the remote machine shall be configured through colord. 
Hence my above discussion of such a situation.

Now you suggest that the local client does colour correct a spooling PDF?
Are you sure? That would be a great feature and much more work than a 
small hook inside CUPS. Nothing indicated, that the colord author wants to 
support that approach.

So far colour conversion happens on the end machine. That is the one,
which is connected to the device. That fits to what Michael Sweet says 
about early versus late colour binding, suggesting that early colour 
binding can cause gigabytes of traffic, while late colour bind will have 
no such issue.

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

Public news stated, that Qt apps are already on Android.

kind regards
Kai-Uwe