Re: [Inkscape-user] CMYK in PDF from Inkscape
El dom, 01-06-2014 a las 13:53 +0000, inkscape-user-request@lists.sourceforge.net escribió:
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.
On Sun, Jun 1, 2014, at 04:08 PM, Gez wrote:
El dom, 01-06-2014 a las 13:53 +0000, inkscape-user-request@lists.sourceforge.net escribió:
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
participants (2)
-
Gez
-
Jon A. Cruz