Perq Accepted for Google Summer of Code 2014


I am happy to announce that the perq project has a place in the 2014 Google Summer of Code!

The quick abstract:

This project will continue work from last summer, which hopes to enable a production print workflow suitable for graphics professionals (“perq”). It will do this by extending the CUPS web interface, and modifying its handling of PPD (PostScript Printer Description) files.

In other words, I will be picking up where I left off in GSoC’13 and perfecting the CUPS web interface for per-queue color management printing. The much-needed CM-off switch will be the focus this summer, where an infrastructure is now available to make this feature work for the perq paradigm.

A lot of stuff can get done in three months, so I look forward to finally bringing this project into fruition.


Google Summer of Code 2013 – Final

Hi everyone,

I have closed the GSoC’13 phase of the Color Management Printing Extension for CUPS project, and moving things forward into actual implementation.

Some samples of my work are the following:

These are essentially prototypes of the web interface when extended to support per-queue color management.

We are open to suggestions, and any input on the extensions are most welcome.


GSoC’13 Project Preview

Hey, everyone.

Just wanted to post a little teaser of my Google Summer of Code 2013 project.

I wrote some documentation to describe the new extensions to the CUPS web interface (1.6.1), and added some screenshots below.

Soon I will post information on how to obtain all of this on my blog.


Using the Per-Queue Interface

This version of CUPS has been enhanced with an interface for per-queue color management, allowing a much easier way for color-savvy users to test and distribute printer drivers in order to produce precise results.

In addition to a new interface, a means to disable color management for a given queue has been included as well. This makes it so that target printing can be achieved on individual queues.

How Do I Use It?

Click on the Printers tab at the top of this page. There you will see the usual interface for managing your printers, along with an additional “Settings” column for each of your queues.

There are two buttons available for each printer. Download simply lets you save the PPD file currently associated with a queue (where available) to your computer. If want to change the currently associated driver, use Replace to upload a PPD file from your hard drive. This will update the queue and mark a time stamp in the “Last Modified” column. Note that if you added a queue, the time stamp will simply display an asterisk (*).

Modifying any queue requires administrative privileges.

Color Management

A feature to enable/disable color management has been implemented. To use it, you will need to select a queue in Printers (listed below “Queue Name”). Once selected, click on the “Administration” combo box located below the header, and select “Modify Printer”.

You will be asked to make the usual changes to a queue, but you will also see a “Color Management” check box option, where a check will enable color management for a printer. Un-check if you wish to use the queue for duties such as target printing.

Color management is enabled by default whenever you add a new queue.

Color-Managed Printing: The View from Krita

The GSoC ‘Color-Managed Printing for Krita’ Project has come to a close.  However, the work shall continue on without the fancy “GSoC” letters!

Over the summer, I have been describing the features of libCmpx, the library used to provide the main components to handle color-managed printing.  This code has finally been integrated into Calligra, providing an initial developer interface:  KoCmpx is a class located in “libs”, providing a print color management base for all Calligra applications, which in turn has been extended into Krita as KisCmpx.  In addition, a “Printer Color Settings” docker has been created to make use of KisCmpx’s profile selection mechanism.

A sample screenshot of the docker is located below this post, as well as diagrams of the code interaction from a developer’s standpoint.

The docker is designed for Krita users to select an ICC printer profile before actually clicking the “print” button.  It provides the option to manually choose a profile (through the use of Krita’s own Color Space selector), or automatically through KisCmpx (requiring that you specify the printer you want a profile from).  Once the printer profile is chosen, KisCmpx saves it into Krita by way of its configuration class.

Choosing a profile for printing is half of KisCmpx’s duty; the other half involves taking that very profile and “attaching” it to a print job.  The idea of the Color-Managed PDF Print Flow is in embedding an ICC profile into a PDF spool file, where the profile is later extracted and rasterized for the printer.  KisCmpx is able to accomplish the first task from within Krita’s “print job” interface, essentially taking your image and converting it into a PDF file.  Having saved the desired profile through the docker, KisCmpx will then re-load the profile and embed it into the PDF image file.

It is important to note that the mechanism to take in a PDF spool file and actually submit it to the printer is not available at the moment.  One of the major pieces implemented so far is the embedding of the ICC profile into the locally created PDF spool file, a job handled by KisCmpx.  However, once there is a way to transport the PDF spool file to the printer and make use of the profile, color-managed printing will then become available.  (And we’re getting very close to that point.)

With all this said, I will continue to try to maintain the ‘printing’ part of Calligra/Krita, and will make the effort to finalize everything into the master repository.  My code can be found in the krita-printing-jsimon383 branch, but it is a little unstable due to the ongoing work.


GSoC’12 Update – Halftime

We are now at the half-way point in the 2012 Google Summer of Code, and the libCmpx/Krita project has seen much progress.

A lot of the work during the first half of GSoC was focused on preparing the library for its integration with Krita.   LibCmpx was still under development prior to the start of GSoC, and had needed its code to be finalized in order to be of use in any application.  The API has since been polished up, and additional features and internal code improvements are now in place in the library.

My previous GSoC-related postings, though slightly technical, had showcased some of libCmpx’s duties in providing printer color management.   At this point,  I am confident to say that libCmpx is finally ready for use.

The focus during the second half of GSoC, then, will be the library’s integration with Krita.  To provide an interface for color-managed printing using libCmpx, I have narrowed down two ways of doing so.  One idea is to implement a docker that will allow you, while working, to select a color profile for print, and at the same time obtain an image preview from that profile.  The other approach is to simply have all of this housed within the standard print dialog that Krita already uses.

It’s important to keep in mind that color-managed printing under Linux is still seen as “under construction”.  The work that I am doing now – interfacing printer color management in the application level –  is just one part of the landscape, and that other projects are actually underway during the summer that will help put together the complete picture.

So while color-managed printing requires the complete picture be available, I will do my best to have things “ready to go” inside Krita.


libCmpx Overview

(Putting it all together!)

Finalized during the 2012 Google Summer of Code, libCmpx provides an easy-to-use API for extending printer color management from within Linux print dialogs.  It is divided into two modules – one to process a color profile based on settings in a print dialog (libCmpx “Selector”) and another to create a color-managed spool file based on that profile (libCmpx “Renderer”).

The library is currently being tested in Krita, which will be the first application to use it.

Please check out the libCmpx wiki page for more information.


GSoC’12 Update – Week 4

Hey everyone.

Week four of the libCmpx/Krita GSoC printer color management project is now coming to a close.

So far I have reached some important milestones in development this week. The libCmpx ‘Renderer’ module (which I talked about last week) has been worked on to the point that all of its major components are functioning, and that PDF rendering is now available for sampling in the test dialog. When both a PDF file and ICC profile is selected from the dialog, the “Print” button will be enabled — Printing in this case simply means that a profile-embedded PDF spool file will be created in your tmp directory. (Remember that only a *copy* of the selected PDF will be created and processed, not the original!)

In addition to finalizing the PDF rendering module, I have improved libCmpx ‘Selector’ so that the “bond” between the module and the printer settings is further tightened. If you recall from my earlier GSoC’12 posting, I had mentioned that a “simulated” printer was actually used in the test dialog, and not the printer(s) installed on your machine. Since printer color management has just started to appear in Linux, printer drivers with color-related attributes are not yet widely available. These attributes – called ColorKeyWords – are used to separate general printing settings (page orientation, number of pages to print, etc.) and color-specific printing settings (color or grayscale, resolution, gamma level, etc.). For automatic ICC profile selection to work inside a print dialog, the color-specific settings would need to parsed and mapped with libCmpx in order to obtain a “best fit” ICC profile.

The custom printer driver file included with the libCmpx test dialog (testprinter.ppd) just so happens to contain these ColorKeyWords attributes, and is used to provide critical color-related settings in the dialog. When you select ‘Automatic’ in the ICC color profile combobox, libCmpx Selector will attempt to find the best ICC profile based on the chosen color settings. If a best fit profile isn’t found from those settings, then libCmpx Selector will obtain fallback profiles from either the printer driver or Oyranos.

Since most of the work done this week was in putting the final touches in libCmpx Renderer, the automatic profile-selection mechanism needs some more tweaks (in most cases, selecting Automatic will simply return sRGB as a best fit profile). So libCmpx Selector will again be put back into the spotlight for week five — and from there, some prospecting on possible integration points in Krita.


GSoC’12 Update – Week 3

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.


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

GSoC’12 Update – Week 2

Hey guys,

Here’s a quick update on what’s been happening with the printer color management project for Krita.

Since last week, much of the work was focused in providing a “communication” link between the individual print dialog settings and the libCmpx Selector module. I have just pushed a major commit today for the library that should tightly bridge the two together, allowing Oyranos (housed inside libCmpx Selector) to properly read these settings and process an appropriate ICC profile. With a little more testing and fine-tuning in the module, half of libCmpx will be ready for integration with Krita.

The next few weeks will focus on the second half of the library, which is the PDF spool rendering module (libCmpx Renderer). Work has already started this week in creating a print preview mechanism in the Renderer module, where Ghostscript will create a color-managed, PNG preview of the PDF spool file.


GSoC’12 Update – Week 1

Hi everyone.

Google Summer of Code has officially started this week, along with the more critical pieces of work for libCmpx.  The timeline that I had planned for the summer is to get libCmpx up to snuff during the first half, and then to integrate the library into Krita during the second.  The latter goal should proceed smoothly if the former has been worked on with care.

This week, I concentrated on extending the libCmpx API to handle obtaining each print option individually.

Originally, the library was only able to obtain printer options that were marked directly from the print driver file (in Linux, “ppd_file_t” for PPDs).  Such a case was convenient only if the driver files were readily accessible from the print dialog application.  In the case of print dialogs like Krita, however, these driver files are usually abstracted away from the dialog programmer. This meant that a better approach for libCmpx is to extract each option string from its corresponding widget.

As shown in the above visual, each option in the print dialog simulator will “hook” onto libCmpx using a function call – “libcmpxCM_setPrintOption()” – which will internally store an option as a key/value pair.  Processing of these options to obtain a profile is emitted by the “libcmpxCM_calibrateICC()” function.  What happens in “auto assign” mode is each color option will be sent into libCmpx’s Selector Module, which will then use Oyranos to rank an appropriate profile based on the selected options.  The user gets full priority for selecting profiles manually, so such processing will not happen for cases like that.

So far, this API addition is partially implemented, but I hope to have this finished soon. During this stage of work, the print dialog simulator will be broken in the meantime, so please bear that in mind if you have been testing it!