[Printing-architecture] Any news regarding colour management?

Tim Waugh twaugh at redhat.com
Thu Jan 6 02:55:02 PST 2011


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part
Url : http://lists.linux-foundation.org/pipermail/printing-architecture/attachments/20110106/ab25545d/attachment-0001.pgp 


More information about the Printing-architecture mailing list