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
