Re: [Printing-architecture] Any news regarding colour management?

[Tim Waugh <twaugh@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1925 bytes --]

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.

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

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

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

Tim.
*/


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]