Colour managed printing under Linux relies on several components to play nicely together. Linux has the great lcms Colour Management Module (CMM) to parse ICC profiles and apply colour transformations based on those. The standard print job PDF can have source ICC profiles attached. CUPS knows about per print queue server side configured output ICC profiles. If feet with the correct settings by the according colour managing print filters, Ghostscript does a great job with the provided information at producing colour corrected raster output using lcms. That output is further processed by the printer driver and spooled by CUPS to the physical device.
PDF contains most often colour values defined in DeviceRGB, which is a very short way to specify some colour. And you know programmers are lazy and simply use that. So Ghostscript does a trick to colour manage these documents nonetheless and assumes DeviceRGB to be meant as sRGB, which is in this situation kind of the best it can do.
But DeviceRGB being handled as sRGB blocks practically two important use cases.
- Advanced application might want to do colour management early inside the application.Think of proofing and other specialised tasks done by designers and PrePress studios.
- Profilers, the applications which create ICC in the first place need targets to be printed without any colour correction. This case is vital to being able to setup colour management at all for new devices, media and drivers by creating valid ICC profiles. It affects owners of colour measurement devices for printers and if they publish their ICC profiles most other users too.
Fortunately there is a way to specify a output device profile per job, which is the way CUPS is designed to be used from client side. Comparably a per session based user device profile introduces a high risk to interfere with standard profile selection mechanisms and concurrenting sessions and is pretty limited in scope. The PDF/X standard allows to embed a output profile inside the document. That way all colour management is completely defined inside the PDF per job and can bypass any unwanted server side magic. The mechanism is called OutputIntent. Applications and print dialogs can use the OutputIntent in order to reliably send device Rgb or Cmyk through a colour management wise non intercepted printing path.
However, manipulation of existing PDF files is not that easy. Thankfully Joseph Simon has put some work into a project called Color-Managed Printing eXtension or short libCmpx. The library handles the harder parts of embedding a ICC output profile into a PDF/X and assists with profile selection. His primary design goal for the libCmpx library is to help enabling colour management in print dialogs. The origin of the project lays in the XCPD Google Summer of Code 2011 project for the OpenICC group.
Is that UML or some “common sense” state diagram? If it’s real UML, kudos to the project – Open Source devs often seem to be avoiding the real development tools for no reason. Also, if it’s UML, it looks like it has it been produced with some kind of TeX package, based on TikZ – the arrows indicate that so it’s really nice to know TeX can do UML.
My experiments in creating UML diagrams in dia where from a graphical point of view never satisfying. But that was already some time ago. As I am a graphics guy, I used Inkscape for all diagrams in this post. They are completely freestyle, so “common sense” might fit best.
Will this be supported in the next KDE (4.9?) release?
It is difficult to say at this point.
There needs to be some more testing with the library – it would be nice to see if we could first use libCmpx on a few other apps that use a print dialog (Krita, for example).
In addition, PDF rendering capability is not quite ready at the moment. However, this is where I am focusing most of my work right now.