Getting CMYK colors from Inkscape to Scribus for printing

Getting CMYK colors from Inkscape to Scribus for printing

The question of getting CMYK PDF output from Inkscape is a very often asked one. Let's talk about getting CMYK colors from Inkscape to Scribus.

In case of Inkscape 0.48 I see that a lot of people read the official release notes and get confused, because they see mentioning of CMYK and don't quite understand what exactly is meant. Hence this article.

First of all, let's explain why there still is no color separated output in Inkscape.

Inkscape relies on Cairo for rendering. It's a great 2D vector graphics library that simplifies lots of things for developers and provides some rendering speed-ups for users, as well as modern antialiased graphics.

The problem with Cairo is that it doesn't yet support CMYK, or, to put in in a more technical language, it doesn't yet support color management, color separation and spot colors. This is not because Cairo folks are not interested in that, but because they don't have a dedicated developer to work on it, and it's a lot of work.

The workaround

Are there any workarounds then? I dare say yes. While Inkscape doesn't do color separation or any of the fancy tricks like trapping, what it can do is saving colors in an ICC profile's color space, and you can tell it which profile to use. Then you can import such an SVG document in Scribus, and it will read the correct CMYK values, if you used a CMYK profile.

The only change in v0.48 regarding color profiles and, therefore, CMYK is that before 0.48 only colors of flat fills could be using color space of an ICC profile. And now with 0.48 color stops of gradients fills can also handle that.

Here is how you do it.

First of all, make sure your profiles are in ~/.local/share/color/icc folder. Then start Inkscape and head over to File / Document Properties (or Ctrl+Shift+D), switch to Color Management tab and pick a profile from the list:

Pick a profile

Then click the Link Profile button. The profile will go the the list of available color profiles:

List of profiles

Now draw an object, open Fill'n'Stroke dialog (Ctrl+Shift+F) and switch to CMS tab. In the combo box pick one of the profiles you linked to from the Document Properties dialog. Et voila!

Color managed color selection

What happens here is that Inkscape reads color space from the color profile and uses available colors, automagically creating sliders for color channel of that space.

If you look inside the SVG file you will see exactly this (follow the selected bit):

Markup in SVG

All you need now is to import this file to Scribus ("File > Import > Get vector file") and make sure it worked:

Result

So let's see:

  Inkscape Scribus
C 0.79987793 80.00%
M 0.51754025 51.76%
Y 0.56966506 56.86%
K 0.33794156 33.73%

Why this small shift? Let's have a little more techie lingo. Inkscape stores values in float, while Scribus uses int. Simply put, those are different ways of storing values, and when you go from one to another, some rounding of values happens.

Now let's see what happens if we don't assign an ICC profile. First of all, colors will be in RGB color space:

What it looks like when it's RGB

Next thing that happens is that when you go from RGB to CMYK in Scribus, color values (K channel aside) turn out to be completely different, even though Scribus uses the very same ICC profile for CMYK:

From RGB to CMYK

One more thing should be mentioned here. Unlike Adobe Illustrator, Inkscape doesn't make you decide whether you work in RGB or CMYK from ground up. As a consequence, in AI you can't use some filters if you go for CMYK, which is not a problem for Inkscape where you can perfectly mix both RGB and CMYK in one document, if you really need it.

Versions and limitations

You need at least Scribus 1.3.5 to support icc-color in SVG. It's up to you whether you want using most unstable 150 branch of Scribus, but the currently existing release candidate for 1.4.0 is safe enough.

Support for icc-color right now is more of a hack that works only when you use CMYK color profiles in Inkscape. It won't work for either RGB or LAB color profiles. Scribus developers made this hack to specifically address the issue of getting CMYK colors from SVG documents to make Inkscape users happier people.

One more thing that should be mentioned in this section is that Scribus doesn't support all of SVG features. Two major features that won't work as you expect them to are SVG filters and text.

As already explained in an earlier article in details, SVG filters are bitmap effects applied to rasterized vector data. In Inkscape they are saved as textual descriptions and are recomputed every time you open that SVG document.

In order to start supporting that Scribus needs to be able to either render these descriptions to bitmaps, save them somewhere and link to these files when loading SVG, or gain native support for SVG filters which means extending its own file format and providing UI for editing filters.

Right now the workaround is to use Edit / Make a Bitmap Copy command in Inkscape for all objects that have SVG filters applied to them (default resolution can be set in Preferences dialog on the Bitmap page). That will embed a bitmap copy into SVG document which Scribus will load just fine. Just keep in mind that those bitmaps will always be in sRGB.

The other issue is text. There are two issues, in fact. First, it will outline all text (that is, convert it to Bezier paths) losing all information about letter spacing and word spacing. Second, it won't import flowing text at all (which isn't surprising given that it's a non-standard feature, but that's another story). So the workaround here, again, is to outline everything in Inkscape to ensure that you don't lose anything. Use Path / Object to Path command for that.

Simply put, importing SVG works best for illustrations that don't use anything but flat or gradient fills, paths and embedded bitmaps.

Spot colors

Another question that is raised at a terrifying rate is what Inkscape does about spot colors. Spot colors are basically fixed names of paints with a fixed recipe by a fixed paints vendor. There are over 300 vendors of spot color catalogs around the globe with Pantone (currently part of X-Rite) being the leader of the industry.

While Inkscape isn't shipped with Pantone color palette which a lot of people seems to expect from it (and which cannot be done due to licensing rules set by Pantone), it does support the essential bit called named colors.

What Inkscape does is compare fill and stroke of a currently selected object to a restricted list of color names defined in the HTML4 spec referenced from CSS2 spec. If the value matches one of those names, the named color is used in the style definition. This feature is optional and disabled by default. To enable it, go to "SVG Output" section of the Preferences dialog.

This doesn't really solve the issue, especially since spot colors have to be written to PDF anyway, which Cairo doesn't do yet, but it could be a first step to something better than that. And thus we arrive to...

A possible short-term solution for spot colors

I can see a way of automating use of spot colors via the Scribus workaround. What needs doing is using named colors in Inkscape, so that instead of icc-color trick or plain RGB values objects used names of colors in style definitions.

Here is a proposed workflow:

  1. Download Pantone palettes from Pantone website, or just use SwatchBooker.
  2. Save the acquired palette to GPL file format (GIMP palette) using SwatchBooker.
  3. Use named colors from this palette instead of RGB values or icc-color in style definitions of objects in your illustration.
  4. In Scribus load the Pantone palette, one way or another.
  5. Run a script to import an SVG document and match named colors to colors from Pantone catalog.
  6. Export your PDF with spot colors.

It sounds quite horrible, but it might just work. What needs doing is:

  1. Patch Inkscape to use named colors other than those 16 colors.
  2. Patch Inkscape to allow using names of colors as you pick them from swatches palette.
  3. Create the Scribus script for mapping named colors to Pantone colors (simple name match).

Few more things should be mentioned.

First of all, Tav mentions in his manual that using named colors can cause some extensions to fail. This should be taken into consideration.

Another potential issue is compatibility. An arbitrary SVG renderer out there won't have a clue about an arbitrary named color from a Pantone catalog. Therefore such a feature should be available only for people who really know what they are doing (if at all).

Finally, there is some slow, but ongoing work by Jon Cruz on the Open Swatch Book project. There already is some infrastructure in Inkscape to address the needs of that project (the Auto color palette and the Swatch button to add colors to it from Fill'n'Stroke dialog), but it is going to take some time to get it done.

So while The Real Solution™, i.e. native CMYK output and support for spot colors, isn't there yet, any takers to improve compatibility between Inkscape and Scribus regarding spot colors which we need anyway?

The long-term solution

When it comes to a real solution, first part of it is going to be covered by upcoming SVG2 specification that extends the existing color syntax to LAB colors, ICC named colors and uncalibrated device color.

ICC named colors look like a nice solution for dealing with spot colors. Unfortunately, there still is the second part which is rendering appropriate PDF output.

Many thanks to ~suv for pointing out specifics of the existing named colors implementation in Inkscape, and to Guillermo Espertino for being insistent on being more specific regarding Jon's work on swatches.

Was it useful? There's more:

8 Comments

Leave a comment
  1. Hi Alexandre,

    Thanks for the detailed guide, it really helped clear things up for me on this issue overall.

    However, I’m very keen to know - did you run into this CMS tab bug?

    https://bugs.launchpad.net/inkscape/+bug/632023

    The bug doesn’t appear to be fixed yet and I encounter this on my dual boot machine running both Linux Mint 12 (Mate desktop*) and Windows 7 64bit.

    I’ve tried using Inkscape 0.48 on both OS’s as well as a three day old development build for Windows only to come up against it there too.

    Which ubuntu release did you use/have working in the screengrabs? For me this is a change distro to whatever works type of deal!

    * For others running LM12 Mate, I had to download and install ICC profiles from the link below just to follow along with this guide.

    http://www.adobe.com/digitalimag/adobergb.html

    For some reason it seemed the profiles were absent from my system…

  2. Alexandre Prokoudine 14 March 2012 at 2:45 pm

    Sure, I did run into this bug and actually reported it :) It’s been a while since I last reproduced it, but probably have to revisit it. The screenshots are partially Ubuntu 10.10, partially 11.04.

  3. Thanks for updating me, I can’t believe I didn’t notice that you reported it! I’m blaming it on a late night researching all this and the fact that it’s also duplicated as Bug #816109, which I found first ;)

    As for the bug itself - I can’t not reproduce it (on either system/inkscape version I mentioned) no matter what I try. That’s why I was so curious as to what your setup was and why it worked for you. Is there any chance the bug could be hardware related? Excuse my ignorance if I’m off track there…

    Anyway,I recently finished my first work using Inkscape and had it printed as a thank you card. You can see the illustration here (minus elements I added prior to printing):

    http://www.nigelmaher.com/2012/03/baby-boy.html

    To do this I exported a png from Inkscape and used Scribus to create a CMYK pdf. It all worked well in that what came back from the printers was pretty much exactly what Scribus showed me.

    Of course some of the brighter blues (in the added elements mostly) really darkened upon conversion in Scribus/the printing process but I was expecting that to occur. For this job, it wasn’t a big deal.

    Your article provides the best information I could dig up on avoiding such pitfalls by working with the correct color profile in the first place. It’s just unfortunate that the feature is itself unsuable for a number of readers.

    Do you know if this might be ironed out for 0.49, or if another workaround that exists?

    Thanks in advance!

  4. Alexandre Prokoudine 14 March 2012 at 6:32 pm

    Well, I’ve just tried again a build from trunk on Ubuntu 11.10 and I can’t reproduce it no matter how much I tweak sliders. I also tried 0.48.3 on Ubuntu 12.04 and it works as well. So I have a gut feeling that it’s either a GTK+ bug that got fixed last year, or an Inkscape bug that was fixed likewise.

    Interesting. I actually ran into your blog and that partcular picture just a couple of days ago :)

    Inkscape’s fill’n'stroke dialog has an out gamut icon that gets enabled when a color is not printable (you need to define an output device profile in preferences for that). So you can kinda know what to expect beforehand, but I guess you figured it out already :) And anyway it’s more like for RGB/CMYK cases.

  5. Thanks for getting back to me with your findings, unfortunately I’m still not having much luck with this issue though.

    Oddly, this bug isn’t present in 0.48 on my netbook running xubuntu 11.10. I installed the standard version from the ubuntu repositories and was pleased to find things working.

    Of course I then installed xubuntu 12.04 beta on my dektop hoping for the same success - to no avail. I tested 0.48.3.1 r9886 from the trunk ppa and found that the very same bug appears every single time I attempt this method.

    Again I’m wondering could it be a partly a hardware issue? It makes no difference whether or not I use a mouse or tablet to try this for what it’s worth.

    My desktop machine does have an radeon card (whereas the netbook uses intel graphics) but I’m not running proprietry drivers for it.

    I don’t know that the bug is actually fixed, perhaps you’re just luckier than myself?

    It’s a shame because I do really want to switch completely to Inkscape for vector work and this is the only issue standing in the way.

    What’s the appropriate channel for me to follow this up?

  6. Just to round this conversation out, I can confirm that after switching to ubuntu 12.04 I’m no longer getting this bug.

    I haven’t tested extensively but it all looks good so far. For the record I’m using 0.48.3.1 from the ubuntu repositories.

    This is great news for anyone needing to work in a CMYK profile on Linux. I’m not sure what the status of the bug in Windows is.

    All we need now is for Scribus to catch up a bit in terms of SVG support (filters/blurs) so getting vector/CMYK PDF’s to a printer is a viable option.

    Thanks for your help Alexandre!

  7. Thanks for posting this. Since there are practically no cmyk color profiles as GPL available, your workaround is a formidable solution to use icc cmyk color profiles in linux.

  8. Alexandre Prokoudine 22 October 2014 at 3:59 pm

    @Fred4,

    How much sense would it make to create free/libre CMYK profiles other than what we already have from Fogra? :)

Tell us what you think

Submit the word you see below: