Can you let a bit of drama enter your life? OK, some more drama? Apparently, Inkscape isn't getting the long anticipated color-managed PDF exporting ability it needs despite the initial work that's already been done.

In July of this year, Adrian Johnson announced the availability of patches that introduce the basics of color management in the PDF backend of Cairo, as well as the relevant functionality in the Cairo-based PDF exporter in Inkscape, a famous free vector-graphics editor. The patches have been bitrotting in a public Git repo ever since then.

What was done

Earlier this year Adrian Johnson, one of Cairo contributors, patched several components to implement tagging PDF objects with color spaces. The following software and system components were affected:

Cairo, the 2D vector graphics library used by Inkscape, GIMP, Scribus and all GTK+ based applications. PDF and PNG backends were patched.

Pixman, Cairo's pixel manipulation library. Adrian added QCMS and LittleCMS based backends to it.

Poppler, a PDF rendering library used by apps like GIMP and Evince (PDF reader in GNOME).

Inkscape, the vector graphics editor.

In the proposed patches, the PDF backend does not do any color conversions. All PDF objects are tagged with their original color space.

PDF exporting options in GIMP

As Adrian explained in a private conversation, he would like to see all of the PDF color space models supported eventually. He started with an RGB only implementation as it significantly simplifies the implementation and it covers most users' needs.

What happened next

On July 11 he mailed the inkscape-devel@ list to tell about his project and ask some specific questions. Unfortunately he got very little feedback.

Two weeks later Adrian mailed the list for Cairo developers and didn't quite get the expected response either. The thread slowly continued to early August and then stopped with no agreements made. No member of 3rd party apps (such as Inkscape) joined in to discuss practical aspects of the proposed API.

So what's the problem exactly?

Why wasn't the work finished? Adrian names three reasons.

First of all, he worked on Cairo in his spare time only, and he doesn't have that time anymore.

The second reason is the lack of interest in his patches:

no feedback on the Cairo list from any color management experts or Cairo users in support of the patches;

no consensus among Cairo developers on whether Cairo should be involved in color management.

Finally, the new API needs a working implementation in Cairo's image backend. Adrian only has experience with the PS/PDF backends, and very little experience with the image backend:

My patches are largely a hack to get something working. I was hoping my API proposal and prototype implementation would generate enough interest in CMS for Cairo to get some help. That has not worked out.

And thus the code is bitrotting in the Git repository now.

Are we in trouble?

Yes, we are. Writing untagged bitmap images (Inkscape only exports PNG) and PDF objects is simply evil. Printing quality becomes pretty much unpredictable, and that could ruin someone's design business.

Furthermore, color managed PDF exporting would open the door to color separated PDF exporting. Without it, we are still down to horrible workarounds like passing the whole design through Scribus and hoping like hell we didn't use any SVG features unsupported by this free desktop publishing app.

CMYK color from Inkscape in Scribus via an ICC profile

As if that wasn't quite enough, Cairo team seems to be somewhat slow at applying patches to the main development branch. For instance, it took the team at least two years to get the gradient mesh support released in a stable version.

None of the big guys to save us?

Inkscape is not the only project that would benefit with color management in Cairo. GIMP also uses Cairo for quite a few things, from rendering tools' widgets on canvas to PDF exporting. And while Scribus already uses it's own internal library to do PDF exporting, it still makes use of Cairo for on-screen rendering on all systems, as well as for printing on Windows. For instance, a PDF spec compliant on-screen rendering with complex transparencies and blend modes would be a certain bonus.

Maybe these teams could get involved?

So far it's unlikely that anyone's from the Inkscape camp is going to take care of color management. Tav seems to be less at home with color, and he's already busy up to his neck with SVG 2.0 related projects. Jon Cruz, the all-things-color developer has an on-and-off relationship with the project. Felipe Sanches who did some relevant development in the past is now busy with his own 3D printing business.

Color management improvements by Felipe Sanches, GSoC2009 project, available since v0.48

The GIMP team is still short-handed, so it's unlikely that they will meddle into the business of such a huge external project. Besides, the top priority right now is to finalize the transition to GEGL and high bit depth processing. All color management related work in the project is handled by one person, and she still is learning as she goes.

I briefly discussed this issue with Jean Ghali from the Scribus project as well. He confirmed that Adrian's patches would be an improvement as complete on-screen rendering as per PDF standards, with all color conversions involved, is currently an extremely difficult task for an opensource project. He also doesn't have time to participate.

So yes — the big guys are out; at least, for now.

Next step

Let's try to put this story into a more constructive perspective. What could you do? Here's what Adrian says:

It would be more helpful to get the support from Cairo users that are using SVG or PDF to talk about what they need. For example the need to support ICC profiles as a source color space, the need for intermediate blending space (sRGB and linear RGB for SVG, ICC for PDF). This is at the level that Cairo developers can understand, it would help to shape the API to achieve this.

If you are an advanced user who understands color management, subscribe to the Cairo mailing list and explain exactly what you need Cairo to do.

If you are a developer who needs Cairo to do handle color management, have a go at the patches (each of the components has a "color-space" branch in Git) and talk to Cairo developers about the proposed API. Explain to them what you need Cairo to do for you.

Unless somebody takes action and fixes the issue, we are going to live with lousy PDF exporting and on-screen rendering for years to come.

Edit (Oct 17, 2012): the discussion in the list for Cairo developers resumed after this article went online. Let's see what happens next.