I've designed a poster in Inkscape 0.91 (on Linux) to have it offset-printed. The printing company requires a CMYK pdf file that uses the ISO Coated v2 (ECI) ICC profile.

Inkscape does not allow export to a CMYK pdf. But I export to an RGB pdf and convert that to CMYK using either Ghostscript or the web service pdf2cmyk. [Some suggest creating a CMYK pdf from Inkscape via Scribus. I can't go that route as Scribus does not recognize the filters I've used in the design.] With either method, I can choose which ICC profile to use in conversion: in this case the Coated one. pdfimages confirms that the resulting pdfs indeed use CMYK.

So far, so good... But:

Within Inkscape, in order to have some idea what the CMYK version of the design would look like, I enabled 'Proofing' (in Preferences > Color Management), using sRGB as the 'Display Profile' and the Coated ICC as the 'Device Profile'. This gives a 'virtual' rendering of the CMYKified, somewhat muted colors. It incidentally shows that the design definitely has colors that are significantly affected by an RGB to CMYK conversion.

But the CMYK pdf produced as described above (export to pdf, convert to CMYK) looks rather different than this proofing rendering suggested by Inkscape. So the proofing does not seem to help in gauging what the CMYK pdf's colors will be like...?

As a test, I did the whole thing over with the ISO Uncoated Yellowish ICC profile. In Inkscape, using that as the 'Device Profile' gives more faded, yellowy colors for the virtual proofing view than with Coated. That seems to make sense. However, when I produce a CMYK pdf using Uncoated Yellowish (once more via export to pdf, convert to CMYK) again it looks different from what Inkscape's proofing suggests. And in fact it looks exactly the same as the CMYK pdf with Coated! Not at all what I expected.

The Coated and Uncoated Yellowish CMYK pdfs have the same file size. So I figured maybe the ICC profile is simply not being taking account of, resulting in identical files. Maybe I'm invoking Ghostscript wrong. But a diff command shows the files to be not quite identical. Moreover, I get a similar result when converting via pdf2cmyk rather than via Ghostscript: Coated and Uncoated Yellowish CMYK pdfs that look the same, and that look very different from Inkscape's proofing suggestions.

Can anyone clear up this fog? Thanks!

  • You say it looks different but don't say where... printed samples? In another PDF viewer? On another machine? In any case, if you aren't working in a calibrated environment you aren't going to see consistent and reliable colors. And ideally you want to see a printed sample first.
    – Cai
    Commented Nov 14, 2016 at 19:52
  • Have you or anybody in your organisation recently hardware calibrated your monitor?
    – joojaa
    Commented Nov 15, 2016 at 6:53
  • @ Cai: Yes, should have clarified that. I mean that on the computer monitor the resultant CMYK pdfs appear to have different colors than the Inkscape proofing suggests (for a given ICC profile).
    – Bryum
    Commented Nov 16, 2016 at 20:34
  • @ joojaa: The monitor is not professionally calibrated. Since the printing company specified that a D50 profile must be used, I used xcalib /usr/share/color/icc/colord/Gamma5000K.icc to change my monitor's color profile. Not sure if that is enough...
    – Bryum
    Commented Nov 16, 2016 at 20:39
  • Meanwhile I tried a different tack. I (1) exported to .png (not .pdf) from Inkscape, and then used ImageMagick (rather than Ghostcript) to (2) convert the .png to .jpg, then (3) convert the .jpg from RGB to CMYK, and finally (4) convert the CMYKed .jpg to a .pdf - which is then basically a container for that .jpg, I think? With this procedure, using different ICC profiles for step 3 gives different-looking (on the monitor) results, which is what I would expect (and contrasts with my attempt with Ghostscript). Time was running out so I've sent the resulting pdfs to the printer. Fingers crossed.
    – Bryum
    Commented Nov 16, 2016 at 20:48

1 Answer 1


Last November you wrote that you have sent your last attempt to the printer. So since you wrote a rather un-precise question, I can easily write an answer:

"Can anyone clear up this fog?" ---> Yes, YOU can.

Please write an update and let us know what you got on paper. And what you learnt for your next job from Inkscape to Offset.

I keep hearing that Inkscape does not handle CMYK and we never send "naked" vector-graphics to a print-shop, we always have text and more stuff in our documents, so our normal work-flow is Inkscape, then import into Scribus. I often have problems getting SVGs from Inkscape into Scribus, eps-exports from Inkscape seems to work better for our types of illustrations. If those do not work, I also export PNG is extreme resolutions and then import to Scribus.

I wonder why you bother to spend time with "virtual proofin" in a program which does not even do CMYK. I work in Africa - so I can only dream about proofs. But I read from several offset print-shops that they can generate you digital-proofs overnight which are not 100% but much much closer to the final print-run than all your guessing on your computer-screen.

  • Hi! I certainly tried to be as precise as possible, though I sure got swamped.
    – Bryum
    Commented Jul 20, 2017 at 13:30
  • This remains unfamiliar territory for me. No, I can't quite clear up the fog. FWIW (not much) I can say that the resulting prints were quite usable but with somewhat less contrast and saturation than desired. Maybe your suggestion of eps-export from Inkscape to Scribus would have worked better?
    – Bryum
    Commented Jul 20, 2017 at 13:42
  • As for the 'virtual proofing': my understanding was that this is a way to assess within Inkscape what the image will roughly look like after conversion to CMYK (even though Inkscape itself does not do such conversion). The intent of my question was to clear up how this, and the other programs mentioned, handle the ICC profiles, because the results confused me. As to "overnight digital-proofs": I don't recall that was an option; moreover, you'd still have to give the printer a best-guess color design, right? It doesn't seem wrong to explore how to do that...
    – Bryum
    Commented Jul 20, 2017 at 13:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.