Hey everyone.
The weather’s been getting warm out here in my part of the Northern Hemisphere. It’s a tempting thought to spend each day at a beach and enjoy the relaxing, cool sounds of ocean waves… but there’s coding to be done!
So here’s the Week 3 update:
In getting the libCmpx/Krita GSoC project closer to its integration phase, I spent the entire week tuning up the library‘s PDF rendering module. This module is all about PDFs, which is a good thing because PDFs will become the spool format used for printing in Linux. This means that every image that you “Print…” in your application will eventually end up as a PDF file by the time it reaches your print server. The aim of libCmpx’s ‘Renderer’ module is to make sure that whatever ICC profile you (or libCmpx’s ‘Selector’ module) choose in a print dialog, it gets used along with the PDF print spool file.
Above is a graphic outlining how the Renderer module is used in the test dialog. One important task this module is assigned to is in the creation of an ICC profile-simulated preview image. If you load a PDF file in the test dialog, getImagePreview() is invoked to generate an “After” image of the file. When using the “ICC color profile” combobox to import a profile — which must be done in this fashion, since at the moment the dialog will only guarantee previewing profiles that you select by hand — Renderer will have Ghostscript create a TIFF preview file using that profile for output. This is a feature that can be beneficial to Krita users, as seeing a rough color sample of the image before it’s printed will save precious ink!
LibCmpx Renderer is also responsible for embedding an ICC profile onto the PDF spool file. This is a required step in the Linux color-managed print workflow, since the color profile information must be transported in some fashion through CUPS. Ghostscript is especially useful in that regard, as it is able to both attach and extract profile data stored in a PDF file (the latter is actually performed from within CUPS). When you click “Print”, a call to setSpoolPdf() will handle modifying* the PDF so that it is color management-aware, meaning that the color profile is embedded in the document and that the proper colorspace has been tagged.
While I have made great strides last week in fixing up Renderer and implementing the new image preview mechanism, more work needs to be done to ensure that errors in this module are put to a minimum. So I will continue to fine-tune the module for next week and eventually enable the “Print” button in the test dialog.
-Joe
*Don’t worry. No changes are made to the file that you selected in the test dialog. A copy is actually created and sent to libCmpx for processing.
Joe's Development Blog 
It would be helpful for those that don’t follow your progress daily to indicate, at the beginning of each post, what your project’s goal is. That would make reading your status updates much easier.
“This means that every image that you ‘Print…’ in your application will eventually end up as a PDF file by the time it reaches your printer.”
Sorry, this is rubbis^W an incorrect statement. You cannot expect everybody to buy a PDF-capable printer.
It means: every image you ‘Print…’ in your application will end up to be handed to CUPS as a PDF file. And CUPS will have to take care to process that PDF file for the job. (Which in turn means to transform it to PostScript, or PCL, or ESC/P or HP/GL or whatever format your real printer consumes….)
PDF is not becoming the file format ‘used for printing’ in Linux. It’s becoming the core format ‘used for print spooling and printjob processing’. Big difference!
Thanks for pointing this out, pipitas. The posting has been edited to clarify that the PDF *spool* file used in Linux will be sent to the print client (CUPS).
-Joe
Joe, it will not be the CUPS *client*, but the CUPS *server* that handles the spoolfile and the format transformation(s) if required. The CUPS *server* is the component that talks to the printer….
To clarify: CUPS consists of two parts, a client and a server part. The way you formulated it now in your main article is OK. But your last comment may lead to confusion…
Pipitas,
I appreciate all the clarification you have been giving here.
With the Linux color management print workflow being considered “experimental” at this point, there is some detail about the CUPS system that I am still sorting out as I am fixing up libCmpx.
So the fact-checking is very helpful in that regard.
-Joe