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.


GSoC’11 Update – Final

Hi everyone.

The last of the GSoC code was committed yesterday.

The following is a modified scheme of Kai-Uwe’s color-managed printer workflow, in which I have added in the necessary calls from XCPD CM to make the steps work:

Two calls from the printer dialog (“xcpdCM_setProfileFromPPD” and “xcpdCM_setSpoolPdf()”) are used to handle both profile-selection and PDF rendering, respectively.  The functions listed below each step represent internal calls to each of the two modules, for which the dialog programmer will need no interest in.

The work that I have done over the summer has managed to put these pieces together by abstracting the workflow, and setting up the necessary test/demo UIs to help diagnose the code (“XCPD Test Suite”).

Profile selection in the XCPD CM code will properly flow through the above sequence, but there remains some polishing internally that need to be made.  Right now I am working with Kai-Uwe in helping pin-point the correct result using the Oyranos CUPS module.  We have with us now a PPD with the necessary ColorKeyWords listing, and a profile with a meta tag containing the print options.  So far, the results using these resources have been promising and with a few more tweaks, we will have a fully-working profile selector.

However, the colorspace tagging in the PDF turned out to be much more difficult than I anticipated.  Mainly this had to do with trying to find a way to parse the PDF by hand in order to remove the ‘DeviceRGB’ /ColorSpace dict item, to which “/DefaultRGB” would be its replacement.  The “DefaultRGB” value has to point to an embedded sRGB profile from within the PDF, which requires the profile object ID  from within the PDF (“/DefaultRGB <<12 0 R>>”, where 12 is the profile object located elsewhere in the PDF).  Parsing for the sRGB object ID and then putting it in with DefaultRGB required a lot of code, which unfortunately did not produce the correct output.  Recently I added some Postscript code for Ghostscript as an alternate solution, but I had to shift focus to work on the profile selection code.

So in essence, the “DeviceXXX* to Default Colour Spaces” step is the only piece that’s not well-implemented in the XCPD CM code right now.

With all this said, however, I will continue to work on polishing up the code even after GSoC.  Time will need to be managed for this to happen, but I can guarantee about 3 more weeks to fine-tune, fix, and answer any concerns that may come up with this model.  Since this is an important item in the printer and color-management circles, I will do my best to make sure the code will function correctly in the actual CPD, as well as write a more generic model that will work for any print dialog.

Thank you everyone for your assistance during the summer!


XCPD Demo App + CM API Tutorial Available

The XCPD Color Management API has been complete and an in-code tutorial of its full usage can be viewed in the “dialog_main.cpp” file (located in ROOT/src/dialog/” directory).

In addition, the “dialog_main.cpp” code contains the pieces for the XCPD prototype model, which can be sampled by clicking on “Launch XCPD Demo” button in the main application.

The dialog is a stripped-down version of the CPD, containing only the code and options that are relavent to color management.  Upon launching the demo, it will ask for a PDF file to test the PDF rendering part of the color-managed workflow (the code here will actually create a COPY of the PDF so that the original file will not be altered).

The focal point of the demo is the “ICC color profile” combobox, which contains the appropriate options for ICC profile selection in the print dialog.  Although at this time the internal code is still underway to properly adjust the profile for all cases, the required XCPD CM API calls are included in the dialog.

There still may be some shaky code that will result in some crashes, in which case I will continue to update the internal code for the next few weeks.  In particular, PDF rendering capability (invoked by pressing the “Print” button) has been commented out in the meantime for fixing and the image preview does not work.

Nevertheless, the prototype is now of use at the moment and taking a chance to look at the “dialog_main.cpp” file will demonstrate of the XCPD CM API’s possible usage in other applications.

‘Profile Selection’ update…

Hi everyone.

Code for the XCPDCM ‘Selection Module’ code has matured to the point where it can be properly tested – the’ Selector Test’ has been modified to properly diagnose the internal code:

The test will find the available printers detected by CUPS and load three sample options for testing.  Choosing an ‘ICC color option’ will set the mode in which the internal code will handle the profile selection process.

Although all the pieces are in place internally, there are some parts of the code that need a little more tweaking before it works 100% — namely, the few parts of the XCPDCM Selector code that call Oyranos (some of that is being corrected at the moment).  This means that the test will most likely return a CUPS fallback if you select “AutoSet”.

The “ApplicationSet” option is the  request for a systems profile, although at this time, the actual CPD does not seem to have specifications on how to handle profiles sent from an application.  In this case, the XCPDCM Selector Module will likely mimic the “ManualSet” option, in which an explicit profile will be set.

GSoC’11 Update – Week 10

Hi everyone.  Here’s my update for Week 10:

At the moment, all of the pieces are in place for the XCPD CM Renderer module. This includes code to check for a PDF/X OutputIntent, embed a profile into a PDF/X, and tagging of the ICC colorspace.   Some work still needs to be done with the ICC colorspace taggging and the changing of the color rendering, but the estimate is that 85% of the PDF rendering functionality is ready.

The changes to the XCPD Renderer code have been committed, which includes an improvement to the Renderer test dialog (a copy of the PDF will now be used to render a file, so it is safe to test any PDF).  Progress was also made on the Selector module last week,  but with the work done that was done recently, the code is still quite broken to be committed.

Much of the work done was actually in pin-pointing a solution for the ICC colorspace tagging, which turned out quite a bit of more work than I thought. The complication that needed to be solved was in handling the case of mixed colorspaces from within a PDF (say, images with both DeviceRGB and DeviceCMYK).

Ghostscript didn’t have a direct solution for this, which meant that I needed to implement solution to hand-code the parsing. A lot of lower-level code was implemented to accomodate parsing for the dictionary items, as well as for replacing the colorspace tags.  It doesn’t quite work right at the moment, but the pieces are already in place and more testing needs to be done.

While doing that, I will be focusing next week on working on committing the updated Selector module code.  Since we’re coming on the homestretch in August,  the frequency of the blog updates will increase and a push towards finishing both modules will continue.


GSoC’11 Update – Week 4

I spent much of Week 4 modifying the internal XCPD CM code to model the finalized XCPD CM scheme, as well as write a basic overview for that model (“XCPD Manual (Part 2)”).  The code is quite messy as a result, and will be cleaned up prior to commiting those changes with git.

With that said, the Ghostscript Interpreter library is now included in the package and is ready to accept rendering commands from XCPD.  The Qt/CPD code that is stored in the bzr repository has now been copied into XCPD, although there are still build issues that need fixing as a result of the move.

With the new pieces in place, writing the workflow code will be much easier now.

Work on both the Profile Selection and PDF Rendering modules will continue for Week 5, as well as writing Part 3 of the XCPD manual – which will focus on the XCPD Color Management API and will include a couple of examples.


GSoC’11 Update – Week 3

Week 3 was squarely focused on implementing the profile selection code.

What is currently available in the git is an updated Profile Selector Test dialog, which shows the proper presets based on the APPrinterPreset attributes in the PPD file.

However, work on the profile-selection module for the test dialog is still not complete. A fix in the xcpdSelector module’s current abstraction is still needed – instead of returning an oyProfile_s* object (with its PPD), an xcpd structure will instead be returned, encapsulating profile, PPD, and related CM information.  That way, *all* internal CM code can be tucked inside XCPD’s Selector module, which itself establishes an abstraction barrier between the print dialog and the profile-selection code.

At the moment, I am writing the draft of a manual that will outline and demonstrate (by way of a tutorial) the capabilities of the XCPD and its CM modules.  My blog will be updated before my next update with the draft, and then eventually polished up for inclusion in the ColourWiki.

While code is still being written for the XCPD’s profile-selector, Week 4 will see the start of the PDF/X module code using Ghostscript.  Simultaneously attacking both problems at once will better help establish a clearer abstraction for the XCPD CM Modules and the new XCPD structure.