Getting CMYK colors from Inkscape to Scribus for printing

Alexandre Prokoudine 23. Sep, 2011
13 Comments

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:

Then click the Link Profile button. The profile will go the the list of available color 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!

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):

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

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:

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:

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:

Download Pantone palettes from Pantone website, or just use SwatchBooker.

Run a script to import an SVG document and match named colors to colors from Pantone catalog.

Export your PDF with spot colors.

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

Patch Inkscape to use named colors other than those 16 colors.

Patch Inkscape to allow using names of colors as you pick them from swatches palette.

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.

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):

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?

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.

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.

im trying to figure out how to print in CMYK and your article is a great help. Unfortunately, i feel there is some information missing as i dont fully understand the whole ICC profile thing.
I read about it on wikipedia, but im not clear on what profile i need to get. (And where.) Its seems there is one for every printer type, and it also seems, it depends on the paper i want to use.

That gives me the impression, i have to work with a specific print service/shop and getting their specific ICC profile, BEFORE i can even work with the colors of my artwork.
Is that correct ?

I am using the inkscape to generate RGB PDF from SVG. Also I am using the ghostscript to generate the CMYK PDF from RGB PDF.
Now I need to generate the Pantone color PDF from SVG/RGB PDF/CMYK PDF.
Is there any way sto generate it from command line software ?

As per your this article scribus can help me to generate the SPOT color PDF. But is there any way to do this with command line. BEcause when I am trying to run scribus command, it generates the below error. scribus: cannot connect to X server

First of all, thank you for the guide. CMYK in Inkscape is a very recurrent topic for graphic designers and it should be very easy to find this kind of informations.

I have a couple of questions :

1) The CMS is ok, but when I work I usually select colors from the palette, since it allows to have the same color with different shaders. Is there a way to create a custom palette with only colors inside the gamut so that people should not check every time the “out of gamut” warning? Is there an application or a website to export a CMYK (let’s say Fogra39coated for instance)palette?

2) For an unknown reason, when I import an svg file to Scribus and I convert colors, on the screen they keep the same. Even if I select the same icc profile. Everything is correct when I export a pdf with the “printer” option selected, but on the Scribus screen colors are different from the Inkscape version. Is that normal ?

1) I can imagine such an algorithm, but I haven’t seen this feature implemented in any software. That said, something like a gamut mask (as seen in e.g. MyPaint, or in GIMP’s sliders since 2.9.8) would probably work for you?

2) I have to admit I haven’t tried this for a long time. Off top of my head: did you try comparing CMS settings between Inkscape and Scribus?

Tell us what you think

Notify me of follow-up comments?

Submit the word you see below:

Support Libre Graphics World

We rely on community funding to publish in-depth articles and news posts. Please subscribe to monthly donations via Patreon: