[Printing-architecture] Any news regarding colour management?

Kai-Uwe Behrmann ku.b at gmx.de
Thu Jan 6 03:44:36 PST 2011

Am 06.01.11, 10:55 -0000 schrieb Tim Waugh:
> On Thu, 2011-01-06 at 11:33 +0100, Kai-Uwe Behrmann wrote:
>> Indeed, that will be very useful. Can you imagine to have that in a
>> generic way, so more CMS's can utilise that capability?
> I think it's already pretty generic actually -- I don't think there's
> anything in colord that ties it to any scheme in particular.  Really
> it's just a small daemon to associate printer queues with ICC files.  I
> imagine (but don't know for sure) that Oyranos CMS could add a small
> hook into colord and that would be all that is required.

Oyranos CMS had developed a very robust approach to select ICC profiles 
for all sorts of devices and drivers. This approach is flexible 
and integrates very well with existing ICC standards.

I see no signs that this will go into colord. So using colord is not an 
option for Oyranos CMS. As users will fall short compared to generaly 
careful, flexible and well integrated information handling in Oyranos.

>> The reason I ask is that Oyranos CMS provides already a lot for
>> configuring and colour managing the desktop and devices. Its going to be
>> integrated into KDE, can run standalone with Xorg or in small devices. So
>> the Oyranos project would be interessted to hook as well into CUPS and
>> tell pstoraster, which ICC profile to use for printing.
> Yes, this is similar to how gnome-color-manager works I believe.
>> I have nothing against D-Bus as is. But is it relly needed in that
>> context? I guess not. A simple convention can reach the same effect and
>> remains open for a heterogenous environment.
> The associations between devices, profiles and ICC files are kept in a
> running daemon which starts on first use, and this is managed by D-Bus.
> I'm sure it could be done another way, but again it just seems the most
> convenient already-implemented way.

It is not convenient to have a new unneeded dependency, when it can be 
done likewise without. The Posix shell is good and enough. D-Bus 
would be a bloated requirement for that simple task.

Please do not confuse this task with typical desktop systems. CUPS and 
Ghostscript are no desktop only software. The printing system needs to run 
on a wide variety of Linux configurations, where the desktop is only a 
small part of.

> Is this sort of system really likely to be needed on a system without
> D-Bus installed?

D-Bus a hard requirement on embedded systems and for servers?

>> The task is to
>> * create a request with meta information (e.g. PPD) to get ICC
>> * send and wait for an answere from command line tool, C interface ...
>> * get the answere and translate it to a ICC profile
>> * use the ICC profile with ghostscript
> That's part of it.  The other part is for the CUPS scheduler to register
> colour profiles and ICC files with colord for each queue on start-up.

Querying ICC profile, which are configured in a CUPS queue, is already 
solved in Oyranos. The CUPS C library calls are fine for that.

> Tim.
> */

kind regards
Kai-Uwe Behrmann
developing for colour management 
www.behrmann.name + www.oyranos.org

More information about the Printing-architecture mailing list