Discussion:
[Inkscape-user] CMYK in PDF from Inkscape
Judah
2014-05-24 14:00:58 UTC
Permalink
Hi all

I have been using inkscape for a while now, my only problem has been a lack
of native CMYK (and spot color) support for PDF's from Inkscape. I was
wondering if there is way to get this piece of software
(moonshiner.sourceforge.net) to work with Inkscape esp in the "Save as" pdf
dialogue? I checked it with an old version of <adobe/> software I have and
the resulting file is definitely in a CMYK color space.
john Culleton
2014-05-24 14:51:10 UTC
Permalink
On Sat, 24 May 2014 14:00:58 +0000 (UTC)
Post by Judah
Hi all
I have been using inkscape for a while now, my
only problem has been a lack of native CMYK
(and spot color) support for PDF's from
Inkscape. I was wondering if there is way to
get this piece of software
(moonshiner.sourceforge.net) to work with
Inkscape esp in the "Save as" pdf dialogue? I
checked it with an old version of <adobe/>
software I have and the resulting file is
definitely in a CMYK color space.
I agree, but CMYK is not covered in the svg
standard. My solution is to import the Inkscape
document into Scribus and then export it
using pdf X/1-a:2001 as the target format.
--
John Culleton
Wexford Press
Free list of books for self-publishers:
http://wexfordpress.net/shortlist.html
PDF e-book: "Create Book Covers with Scribus"
available at
http://www.booklocker.com/books/4055.html
Jon A. Cruz
2014-05-24 19:26:11 UTC
Permalink
Actually SVG does allow for proper CMYK, as does Inkscape. It is just that the export path we use (Cairo) does not support CMYK.
Post by john Culleton
On Sat, 24 May 2014 14:00:58 +0000 (UTC)
Post by Judah
Hi all
I have been using inkscape for a while now, my
only problem has been a lack of native CMYK
(and spot color) support for PDF's from
Inkscape. I was wondering if there is way to
get this piece of software
(moonshiner.sourceforge.net) to work with
Inkscape esp in the "Save as" pdf dialogue? I
checked it with an old version of <adobe/>
software I have and the resulting file is
definitely in a CMYK color space.
I agree, but CMYK is not covered in the svg
standard. My solution is to import the Inkscape
document into Scribus and then export it
using pdf X/1-a:2001 as the target format.
--
John Culleton
Wexford Press
http://wexfordpress.net/shortlist.html
PDF e-book: "Create Book Covers with Scribus"
available at
http://www.booklocker.com/books/4055.html
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Inkscape-user mailing list
https://lists.sourceforge.net/lists/listi
Judah Kleinveldt
2014-05-25 19:01:52 UTC
Permalink
Post by Jon A. Cruz
Actually SVG does allow for proper CMYK, as does Inkscape. It is just
that the export path we use (Cairo) does not support CMYK.
Hi Jon Cruz
Its a pity Cairo doesn't support CMYK. I would really like to know how
you can convert the colorspace of an svg file, I have exported a CMYK
file exported from Illustrator but it has not retained its colourspace.
AFAIK editing the xml colour tag in a text editor is the only way to get
the svg file to include CMYK or spot colour info, please could you share
your method of you do this.
Post by Jon A. Cruz
Post by john Culleton
I agree, but CMYK is not covered in the svg
standard. My solution is to import the Inkscape
document into Scribus and then export it
using pdf X/1-a:2001 as the target format.
Thanks John Culleton,
My current work around is to do just that or in most cases I change the
colourspace of the pdf (including and especially images) using
moonshiner. It doesn't always not retain CMYK colour values for vector
objects, it is an extra step I would like to avoid. I was wondering if
anyone else has been successful in using Ghostscript to convert the
colourspace of a PDF, but integrated into the export dialogue maybe as a
plugin. Its a slight hassle to import an SVG file, update the CMYK info
on each object,export to PDF, send the file to my local printer, do a
proof print with them, change the colour again in Scribus, export to
PDF. I guess I will just have to continue along this way of doing
things, until I have figured out how to what I want myself :)

Please forgive if this email looks odd, I'm still looking for a mailing
list reader to respond to posts on the list.
Jon A. Cruz
2014-05-25 19:16:22 UTC
Permalink
Post by Judah Kleinveldt
Hi Jon Cruz
Its a pity Cairo doesn't support CMYK. I would really like to know how
you can convert the colorspace of an svg file, I have exported a CMYK
file exported from Illustrator but it has not retained its colourspace.
AFAIK editing the xml colour tag in a text editor is the only way to get
the svg file to include CMYK or spot colour info, please could you share
your method of you do this.
For CMYK values, I had a writeup done a while back.
http://codewideopen.blogspot.com/2010/10/inkscape-does-support-cmyk.html

SVG 1.x does not truly support spot colors, but internally a single-stop
gradient has been implemented. I've not checked on the to-print workflow
with those. SVG 2.x was adding better colors, but we'll need to code
more to catch up with that.


Also... the CMYK/Spot color workflow is fairly simplistic and dated. We
need to revamp the workflow to make it easier on designers to setup and
use different target print workflows.
--
Jon A. Cruz
***@joncruz.org
Gez
2014-05-25 20:47:54 UTC
Permalink
Post by Judah Kleinveldt
My current work around is to do just that or in most cases I change
the
colourspace of the pdf (including and especially images) using
moonshiner. It doesn't always not retain CMYK colour values for vector
objects, it is an extra step I would like to avoid. I was wondering if
anyone else has been successful in using Ghostscript to convert the
colourspace of a PDF, but integrated into the export dialogue maybe as
a
plugin. Its a slight hassle to import an SVG file, update the CMYK
info
on each object,export to PDF, send the file to my local printer, do a
proof print with them, change the colour again in Scribus, export to
PDF. I guess I will just have to continue along this way of doing
things, until I have figured out how to what I want myself :)
Hi Judah,

You have to attach a CMYK color profile to your inkscape document in the
document properties. Once you have the profile, the CMS tab in the
fill/stroke dialog allows you to choose the colorspace for each object
and select your desired CMYK values.
If you do that and take the SVG file to Scribus, the CMYK values will be
honored.
Regarding the spot inks, as far as I can remember you can use the auto
palette for adding swatches that work "globally" in the document, but
since that's done by custom gradient definitios they don't survive the
import to Scribus as spot inks.
It's not really a problem, since the color of a spot ink is meaningless.
The color of spot inks is just a visual aid for you to pick them, but
the printer will produce a separate plate for them that has to be inked
with the right color.
So, don't worry about spots in inkscape then. Just use a regular RGB
color and when you import the SVG to Scribus, go to the colors manager
and turn that RGB swatch to a spot ink, using the name of the desired
ink so it's reflected in the PDF output. The printer will know what to
do with it.

I run a small graphic design firm, and I send files to printshops almost
daily. Personally, I don't even care about doing anything in CMYK in
Inkscape. I do everything in RGB, and let Scribus to create the
separations.
Spot-only works are the exception, of course. But since printing 3 spots
is usually as expensive as printing process, most of the jobs end up
being just process, with a few exceptions.
CMYK+Spots is not very common as one would expect, but it's not a
problem if you use the intermediate binding process I just described.
You do everything in RGB, and if something has to be printed in a
special ink, you can mark the RGB swatch as spot in Scribus and it will
take care of it.
In my experience, properly color managed RGB > CMYK conversions are
pretty reliable. Designers usually think that a special CMYK combination
is a bullet-proof method to get exact colors, but that's not true: a
certain CMYK combination is tied to a specific press setting (plate
order, screen angle, stock type and quality, etc.)

Gez.
Chris Mohler
2014-05-26 01:13:11 UTC
Permalink
I just did a gig where the client needed the source done in Inkscape,
but needed CMYK output for submission.

What I did, IIRC:

1. Attached a color profile to the Inkscape doc

2. Made sure all the objects had a correct color in the 'CMS' tab on
the 'Fill/Stroke' dialog.

3. Imported the SVG into Scribus (after converting text to paths).

4. Exported PDF v1.3 with 'output' set to 'Print' (instead of 'Screen'/Web').

I'm skipping a few steps here (eg, having to resize), but that's the
gist of what I did. The colors matched when I double-checked the
final PDF in Illustrator.

I my case, I had a bunch of small (11pt) text that *had* to be 100% K
and not rich black (which is what I was getting from straight-up PDF
export from Inkscape), which is why I had to go through the
import/export step in Scribus.

HTH,
Chris

PS - I agree in principle about being able to submit RGB files, but
for certain edge cases (rich black, spot colors, pure CMY, etc), not
having CMYK export is pure pain. And it seems like all of the
publishers/printers (in the US at least) insist on CMYK files for some
reason (which sucks, really).
Judah
2014-05-28 08:34:48 UTC
Permalink
Wow such community.

Thanks all for the replies, with a lack of a good mailing list reader I
have to reply generally or top post so forgive any confusion that might
come from this.

My original post was a feeler to see if anyone may have been successful
in creating a pdf in CMYK colourspace straight out of inkscape using
ghostscript/monshiner, instead of the extra step in Scribus.

Chris they insist on CMYK because the inks used are C=Cyan M=Magenta
Y=Yellow K=Black and the plates they use are separations of/to these
colours/inks.

Gez, I know inkscape doesnt really work well for a purely CMYK workflow,
I knew that from the start. I must say that your statement about CMYK
values tied to press settings are not what I, nor anyone I know in
print and design have been doing, maybe your statement would make more
sense(for me anyway) if you mentioned that printer ICC profiles are tied
to specific press settings.

Even so, thanks all for the responses I'll have to continue using the ICC linking method in the mean time.
Chris Mohler
2014-05-28 19:14:33 UTC
Permalink
Post by Judah
Chris they insist on CMYK because the inks used are C=Cyan M=Magenta
Y=Yellow K=Black and the plates they use are separations of/to these
colours/inks.
When I was running the print shop (small operation), we insisted on
CMYK files too. But mainly because we were sick of people sending in
R:0 G:0 B:255 and getting the complaint "what can't it be as blue as
it is on my screen?" ;)

I still tend to "mid-bind" these days if I can, or early bind. Rich
black vs. 100%K is a constant issue in a lot of the stuff I'm putting
together. And to be honest, I tend to use Inkscape to draw a portion
of a layout rather than put together the complete design. I just
threw my process out there because I just went through the project
where the client insisted that the source file be created in Inkscape,
and also needed a CMYK PDF to submit to the publisher.

tl;dr - I agree, good luck ;)

Chris
Gez
2014-06-01 23:08:24 UTC
Permalink
El dom, 01-06-2014 a las 13:53 +0000,
Post by Judah
Gez, I know inkscape doesnt really work well for a purely CMYK
workflow,
I knew that from the start. I must say that your statement about CMYK
values tied to press settings are not what I, nor anyone I know in
print and design have been doing, maybe your statement would make more
sense(for me anyway) if you mentioned that printer ICC profiles are
tied
to specific press settings.
Man, saying that a printer ICC profile is tied to specific press
settings and saying that a specific set of CMYK values is tied to
specific press settings is the same.
Are you saying that they are different things and a specific set of CMYK
values will print the same in any press?
If that's what you're saying you and "anyone you know in print" are
wrong. :-p

But don't take my word, just grab two Pantone Bridge books, one for the
US market and the other for the Euro market and explain why the same
Pantone colors have different values when "converted" to CMYK.

Also check the press settings stated in those books, and you'll see that
the print setup varies.
Why do you think they do that?

Your CMYK values are meaningless if you don't know the colorspace
they're tied to. Your CMYK values won't print the exact color you want
if you take them to two different presses with different setups and
paper stocks.

Of course they are tied to the press settings, and ICC profiles are how
you communicate it to the color management engine.

Anyway, maybe you missed the point of what I tried to say (or I did a
lousy job explaining it, it's possible too :-)
The point is that you can get good results with a intermediate binding
workflow. I'm not saying that you should send RGB.
If you do everything in RGB in Inkscape and let Scribus to convert the
RGB values to the desired CMYK profile, you'll get good results.
As Chris pointed out, there are some aspects that have to be considered,
and black type is one of them.
If your print provider doesn't have the specific preflight rules for it,
black will be printed as composite black and you don't want that for
your small type.
In that case, you can replace the RGB black 100% K in Scribus (or in
inkscape with the CMS tab before taking the SVG to Scribus).

As I mentioned in the other mail, I do that all the time with excellent
results, and some of the stuff I do that way goes to top print providers
who print large runs for national distribution. Believe me I wouldn't
use this software for that if I wasn't sure about it.

Gez.
Jon A. Cruz
2014-06-05 16:55:30 UTC
Permalink
Post by Gez
El dom, 01-06-2014 a las 13:53 +0000,
Post by Judah
Gez, I know inkscape doesnt really work well for a purely CMYK
workflow,
I knew that from the start. I must say that your statement about CMYK
values tied to press settings are not what I, nor anyone I know in
print and design have been doing, maybe your statement would make more
sense(for me anyway) if you mentioned that printer ICC profiles are
tied
to specific press settings.
Man, saying that a printer ICC profile is tied to specific press
settings and saying that a specific set of CMYK values is tied to
specific press settings is the same.
Are you saying that they are different things and a specific set of CMYK
values will print the same in any press?
Yes, generally a designer creating something CMYK for print needs to
know *which* CMYK they are using. Some of the common names include SWOP,
GRACoL, FOGRA, and SNAP. Note that there are several of each of these,
such as "SWOP v2", FOGRA39, etc.

I had a blog post a while back about how abstract CMYK is meaningless.
http://codewideopen.blogspot.com/2010/09/cmyk-is-meaningless.html
--
Jon A. Cruz
***@joncruz.org
Judah
2014-06-02 11:57:58 UTC
Permalink
Post by Gez
El dom, 01-06-2014 a las 13:53 +0000,
Post by Judah
Gez, I know inkscape doesnt really work well for a purely CMYK
workflow,
I knew that from the start. I must say that your statement about CMYK
values tied to press settings are not what I, nor anyone I know in
print and design have been doing, maybe your statement would make more
sense(for me anyway) if you mentioned that printer ICC profiles are
tied
to specific press settings.
Man, saying that a printer ICC profile is tied to specific press
settings and saying that a specific set of CMYK values is tied to
specific press settings is the same.
Are you saying that they are different things and a specific set of CMYK
values will print the same in any press?
If that's what you're saying you and "anyone you know in print" are
wrong. :-p
It's supposed to but it isn't. My point was that a CMYK colour is
determined by the values you in put, of course there are tons of
variables that determine if we actually get this colour but a CMYK break
down is just that, a breakdown of how the inks will mix. 10%=Cyan, 15%
=Magenta, 30%=Yellow 40%=Black, you are asking the printer to mix his
inks with these values.
Post by Gez
But don't take my word, just grab two Pantone Bridge books, one for the
US market and the other for the Euro market and explain why the same
Pantone colors have different values when "converted" to CMYK.
No dispute on this at all, I agree.
Post by Gez
Also check the press settings stated in those books, and you'll see that
the print setup varies.
Why do you think they do that?
You cant give a printer a RGB image and say just print this to this
profile it should be fine. Your image should be teh correct
colourspace.
Post by Gez
Your CMYK values are meaningless if you don't know the colorspace
they're tied to.
The colourspace is CMYK, the profile will depend on the output.
Post by Gez
Your CMYK values won't print the exact color you want
if you take them to two different presses with different setups and
paper stocks.
CMYK values specify a colour, I agree that I wont get the same colour
from any printer, their setups vary. Colours will appear differntly on
different stock, but it is the the profiles that change the CMYK values
to be better suited for coated/uncoated stock and print processes. Don't
believe me Link two different profiles and see if the colour remains the
same even with 100K. The profiles change the values. The values
determine the colour.
Post by Gez
Of course they are tied to the press settings, and ICC profiles are how
you communicate it to the color management engine.
I am saying that CMYK values determine a specific colour not ICC
profiles. ICC profiles will change the CMYK values so that you have the
colour you want based on your output.
Post by Gez
Anyway, maybe you missed the point of what I tried to say (or I did a
lousy job explaining it, it's possible too :-)
Well I'm sure we can hash this out forever, we both have workflows that
have been working for us in a practical sense. Oneday when I visit your
country I will be sure to look you up and we can do it over a beer or
six.
Post by Gez
The point is that you can get good results with a intermediate binding
workflow. I'm not saying that you should send RGB.
Yeah for graphics, but what happens when you have an image. I wanted to
know if we can save a purely CMYK file WITHOUT the extra step in
scribus. We can't because cairo doesnt fully support CMYK.
Ghostscript does, this was my question, it there a way to use
ghostscript in the output PDF from Inkscape.
Post by Gez
If you do everything in RGB in Inkscape and let Scribus to convert the
RGB values to the desired CMYK profile, you'll get good results.
As Chris pointed out, there are some aspects that have to be considered,
and black type is one of them.
If your print provider doesn't have the specific preflight rules for it,
black will be printed as composite black and you don't want that for
your small type.
In that case, you can replace the RGB black 100% K in Scribus (or in
inkscape with the CMS tab before taking the SVG to Scribus).
I'm not disputing this, this is the only to do it. I was asking can we
make a fully CMYK colourspace pdf from inkscape using ghostscript,
seeing as how cairo doesnt fully allow for this.
Post by Gez
As I mentioned in the other mail, I do that all the time with excellent
results, and some of the stuff I do that way goes to top print providers
who print large runs for national distribution. Believe me I wouldn't
use this software for that if I wasn't sure about it.
Same here, I would have left it ages ago, I find it works best for
logo's and web graphics and it does what I need except give me a CMYK
colourspace PDF without going into Scribus or Moonshiner.

I don't really want to continue with this thread, whatever you say next
I will agree to (depends on what you say, but I will) and we can
put it to rest.

Judah
john Culleton
2014-06-02 18:43:29 UTC
Permalink
On Mon, 02 Jun 2014 13:57:58 +0200
Post by Judah
Post by Gez
El dom, 01-06-2014 a las 13:53 +0000,
Post by Judah
Gez, I know inkscape doesnt really work
well for a purely CMYK workflow,
I knew that from the start. I must say that
your statement about CMYK values tied to
press settings are not what I, nor anyone I
know in print and design have been doing,
maybe your statement would make more
sense(for me anyway) if you mentioned that
printer ICC profiles are tied to specific
press settings.
Man, saying that a printer ICC profile is
tied to specific press settings and saying
that a specific set of CMYK values is tied to
specific press settings is the same. Are you
saying that they are different things and a
specific set of CMYK values will print the
same in any press? If that's what you're
saying you and "anyone you know in print" are
wrong. :-p
It's supposed to but it isn't. My point was
that a CMYK colour is determined by the values
you in put, of course there are tons of
variables that determine if we actually get
this colour but a CMYK break down is just that,
a breakdown of how the inks will mix.
10%=Cyan, 15% =Magenta, 30%=Yellow 40%=Black,
you are asking the printer to mix his inks with
these values.
Post by Gez
But don't take my word, just grab two Pantone
Bridge books, one for the US market and the
other for the Euro market and explain why the
same Pantone colors have different values
when "converted" to CMYK.
No dispute on this at all, I agree.
Post by Gez
Also check the press settings stated in those
books, and you'll see that the print setup
varies. Why do you think they do that?
You cant give a printer a RGB image and say
just print this to this profile it should be
fine. Your image should be teh correct
colourspace.
Post by Gez
Your CMYK values are meaningless if you don't
know the colorspace they're tied to.
The colourspace is CMYK, the profile will
depend on the output.
Post by Gez
Your CMYK values won't print the exact color
you want if you take them to two different
presses with different setups and paper
stocks.
CMYK values specify a colour, I agree that I
wont get the same colour from any printer,
their setups vary. Colours will appear
differntly on different stock, but it is the
the profiles that change the CMYK values to be
better suited for coated/uncoated stock and
print processes. Don't believe me Link two
different profiles and see if the colour
remains the same even with 100K. The profiles
change the values. The values determine the
colour.
Post by Gez
Of course they are tied to the press
settings, and ICC profiles are how you
communicate it to the color management engine.
I am saying that CMYK values determine a
specific colour not ICC profiles. ICC profiles
will change the CMYK values so that you have
the colour you want based on your output.
Post by Gez
Anyway, maybe you missed the point of what I
tried to say (or I did a lousy job explaining
it, it's possible too :-)
Well I'm sure we can hash this out forever, we
both have workflows that have been working for
us in a practical sense. Oneday when I visit
your country I will be sure to look you up and
we can do it over a beer or six.
Post by Gez
The point is that you can get good results
with a intermediate binding workflow. I'm not
saying that you should send RGB.
Yeah for graphics, but what happens when you
have an image. I wanted to know if we can save
a purely CMYK file WITHOUT the extra step in
scribus. We can't because cairo doesnt fully
support CMYK. Ghostscript does, this was my
question, it there a way to use ghostscript in
the output PDF from Inkscape.
Post by Gez
If you do everything in RGB in Inkscape and
let Scribus to convert the RGB values to the
desired CMYK profile, you'll get good
results. As Chris pointed out, there are some
aspects that have to be considered, and black
type is one of them. If your print provider
doesn't have the specific preflight rules for
it, black will be printed as composite black
and you don't want that for your small type.
In that case, you can replace the RGB black
100% K in Scribus (or in inkscape with the
CMS tab before taking the SVG to Scribus).
I'm not disputing this, this is the only to do
it. I was asking can we make a fully CMYK
colourspace pdf from inkscape using
ghostscript, seeing as how cairo doesnt fully
allow for this.
Post by Gez
As I mentioned in the other mail, I do that
all the time with excellent results, and some
of the stuff I do that way goes to top print
providers who print large runs for national
distribution. Believe me I wouldn't use this
software for that if I wasn't sure about it.
Same here, I would have left it ages ago, I
find it works best for logo's and web graphics
and it does what I need except give me a CMYK
colourspace PDF without going into Scribus or
Moonshiner.
I don't really want to continue with this
thread, whatever you say next I will agree to
(depends on what you say, but I will) and we
can put it to rest.
Judah
Inkscape and Gimp both need to accommodate the
CMYK color model and also provide a correct PDF
X/1-a:2001 output to be fully useful to those of
us who prepare books for printing. The Context
version of TeX has finally come around to this
latter requirement.
--
John Culleton
Wexford Press
Free list of books for self-publishers:
http://wexfordpress.net/shortlist.html
PDF e-book: "Create Book Covers with Scribus"
available at
http://www.booklocker.com/books/4055.html
Continue reading on narkive:
Loading...