2012/3/14 Kai-Uwe Behrmann <[email protected]>: > 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. No. Cups uses the Color Management system provided by the OS. On MacOS-X it uses ColorSync, for example. Cups itself has a patch included which makes it use colord DBus-API to talk to colord. That's the reason for CUPS recommending colord on Debian.
>> 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 does - on MacOS-X, because it uses ColorSync there :P Regards, Matthias >>> 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
