Review Request: include KolorManager in kdegraphics

[Kai-Uwe Behrmann]

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.

>> it is a gnome project, and it's widening its scope. The
>> reason it's used at all is that is is used inside gnome.
>
> Projects should be judged on merit, irregardless of who pushes it.
> If gnome is using it and that makes it grow acceptance, thats a good thing in
> my book.  Why; *because* acceptance is growing. I don't care if its gnome or
> any other player pushing it.
>
> That said; Cups also depends on colord. And IMO that has a bigger impact than
> the gnome components that pull it in.

CUPS has a own CM spec, which works for vendor side profiles. That 
CMS exists completely outside of any DE or other CMS.

colord print CM:
CUPS does not depend in any way on colord. But colord depends on CUPS to 
support it's concept of placing colord's session centric configuration 
into each job on server side. I do not know how to support per session 
configuration remotely or how to assign to the proper users.
It does not scale well and will likely be difficult to maintain. That is 
one of the major and long standing critique points. The colord author 
repeatedly said it is fine, without delivering arguments, except it is 
the fastest way to implement.

OpenICC print CM:
One idea of OpenICC members is to let users configure a per queue 
device profile with CUPS' own means. Thus it is best support inside CUPS. 
We would like to support that in KolorManager or where appropriate
The worked on alternative is libCmpx, which embedds the user selected 
device profile inside the print job PDF/X-3. PDF/X-3 as a standard will 
likely work cross platform, which will be important to scale clouds and 
elsewhere. These two concepts appear much robuster and are proven to work 
on other operating systems. Mike Sweet confirmed that for the later, while 
the other concept is deployed on Windows by some drivers.

Here some more details about the later aproach:
http://www.oyranos.org/2012/02/linux-printing/

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