Recently Felipe "JucaBlues" and I were hashing out some next steps for development, when I realized that Inkscape should NOT "support CMYK." Given that the Brazilian user community has really been pushing progress on the adoption of Open Source, including the use of Inkscape in print work, this might seem a bit surprising. 
However as we have been moving forward, implementing things, and trying to really support more and more professional use of Inkscape, the problem has become a bit clearer. What it seems to come down to is that we need to be sure to not get caught up in the low-level "how" of implementation of "four color CMYK" and instead change to focus on the higher-level "why" of "supporting prepress work." To get good, reliable, professional results in all forms of image work is a good thing, and people being able to get work done, and well, is key.
People who don't work towards print output are not often as familiar with CMYK and a CMYK workflow. What people are familiar with, at least when it comes to computer imagery, is RGB. GIMP, for example, has worked in RGB for the longest time (though it is now getting updated with new internals that will make working for print output much nicer). RGB images are split into three components: Red, Green, and Blue. Colors might be chosen with different modes (such as HSL), but are generally are stored in RGB. For photographs, web work, etc., RGB image work can be quite sufficient, and sometimes even preferable. There are also subtle variations such as sRGB, wide gamut RGB, Adobe RGB, etc. that can be used for specific needs.
Whereas RGB is creating colors by mixing three light primaries in additive color, CMYK is used with mixing four ink primaries in subtractive color. In general this is done by inverting the three RGB primary colors into inks and then adding a fourth ink that is plain black. This helps with getting true black, avoiding oversaturate paper, and other factors. Print artist often like working directly in CMYK so they can control sharpness of text, overprint of color, etc. However, the first big trap is that there is no such thing as "the CMYK colorspace." 
CMYK numbers/values are actually dependent on a specific device, and even two printers of the same make and model usually will give different results for the same input numbers. Given that an artist will choose to work in CMYK in order to more precisely control the output of a job, it is critical that color management is involved in the CMYK workflow to target specific jobs. Working on a job to be printed in a glossy magazine can be very different than one to be printed in a local newspaper.
SVG has been able to support CMYK via ICC profiles, and Inkscape has supported that in rough form since 0.46. Felipe and I have improved the interface for this more in 0.47, but there is still more to go. We also have been working with Scribus to help ensure color-managed SVG files become well supported. Some recent work for SVG 1.2 has added device-cmyk, but it turns out that this is for workflows that are not color-managed, and thus not really what end users need.
The other significant complication with a focus on "CMYK work" is that many professional jobs that are to go to print are not really "four color" at all. They might have four-color printing as part of the job, but then spot colors come in and easily expand to five-color, six-color and more. 
A company, for example, will often have a precise color they use for their logo, and this will be printed on its own plate in a pass of just that specific ink. UV coating, embossing and other effects might require their own color or 'channel'. 
Anyone who has ever heard "Pantone" mentioned has probably bumped up against this "not-just-four-colors" problem. And in addition to spot colors, modern printers have been expanded to use six or more colors, not just four, in order to get better results.
What that means is that to properly support end users needing to work on art that is going to be printed, Inkscape will need to support far more than only four colors. And more than just CMYK is a given (that spot color issue again). Artist will need to easily pick a target CMKY ICC profile for all jobs, have multi-color support preserved, handle spot colors and custom palettes, etc. So when it comes time to implement features, thinking only of CMYK will most likely lead to solutions that hurt, rather than help. So remember, think "professional prepress work" and not "CMYK work".
(Images 
This work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License. Original apple image by Jan Mehlich)
16 comments:
I was afraid this was going to turn into another rant with excuses being made for why CMYK isn't supported but luckily it isn't.
You're right in that it isn't just about CMYK but supporting lots or few colours. BTW, did you see the talk at LGM from the GIMP developer who said similar things?
Well - if you have to do this in the professional manner, this means you have to implement only on thing:
Professional color management. Period.
How to do it? Look at Illustrator. Read. Ask. Do it like others did. Don't reinvent the wheel.
If you lack bizilion of colours from 200 palettes - just wait, community will do it for you. Just give it the abilities.
If you call current CMYK support and color managment in Inkscape a "CMYK support" - you're joking, right?
Not supporting CMYK things in GIMP and Inkscape:
Makes developers look like were paid by Adobe.
Targets non-printing or poorly-printing user only.
Forces printing guys to use other software.
If you say color management is a part of prepress - you're very wrong. Its a part of any serious digital graphics.
Rasterizing, proof-printing, offset plate preparation processes - this is all pre-press. You're not even close to it. Even adding cutting/binding marks is NOT a part of pre-press (but it IS DTP job). And TAC (total C+M+Y+K+others) limiting should be done IN the design process by designer artist or his after-worker somewhere in DTP chain.
I know I'm not Inkscape developer, so that my speech is worth almost nothing. But I'm "printing" artist (and DTP guy) with freedom as priority, and doing anything printable is since forever pain in the ass with FLOSS software. TeX/LaTeX maybe makes some things easy (but not for artists/designers).
Not including full color management proves both GIMP and Inkscape developers are not serious in what they want to achieve.
So, if I understand correctly (my experience with printing is extremely limited), this means: Inkscape and professional printing - this ain't gonna happen any time soon
Nicu, not at all. What this means first is that a professional color-managed workflow sufficient for going to print is a bit tricky... one really has to do it all.
However, the good news is that technically things have been put in place so that Inkscape really just needs some GUI magic to pull it all together. It supports ICC profiles, does on-screen soft proofing, etc. We just need to be sure people remember the big picture and don't try to do shortcuts like device-specific color, non-color-managed workflow, etc.
Probably the number one thing that is needed is some good feedback from different types of users. (I'll get a wiki page set up to collect that)
And I believe the final step will be to get print optimised PDFs as export, since the print shops will not bother to adopt their workflow and accept SVG
How to do it? Look at Illustrator.
If only to look away next :)
The way Illustrator separates RGB documents form CMYK documents and doesn't allow using any SVG filters in CMYK documents drives me nuts.
prokoudine I'm sure you'll find good example of "color-able" app, producing good results in printing. Illustrator is not nearly as transparent (in terms of gui), as it should, but it works and does its work well in printing industry since years.
Corel does lots of error (but its good enough to most of production tasks), and frankly I don't have a clue about the other tools.
Jon - no offense again - "that technically things have been put in place so that Inkscape really just needs some GUI magic to pull it all together" - would it show cyan *as it looks after printing*? Would I be able to make black rich or some parts flooded or overprinted?
Lukasz, for the most part, yes.
That is, if you attach a CMYK ICC color profile to be used, then that will tell Inkscape (via LCMS) and others the details of the ink, paper and printer and those will be used for on-screen soft proofing. And if you have a screen profile explicitly set (or an automatic per-monitor one from X11) then Inkscape will also use that to correct your display.
As to controlling actual overprint, trapping, etc. the best workflow will be to import SVG into Scribus. One can do many things manually in Inkscape, but Scribus has been focused on professional print work for some time now. So in Inkscape at the moment you won't be able to zoom in and see actual dots simulated, but you will get a color-managed and corrected representation.
Of course it works in Illustrator since all the printing process has been based on EPS and since Illustrator, from the beginning has been an EPS editor. Moving to new release doesn't change anything to me. I think Adobe's process is crap because this is not a support (since you can nearly do nothing in CMYK). Plus if you read Adobe documentation they advise to work as long as possible in RGB. CMYK should be used only at export time
Jon - it is really nice to have any kind of soft-proofing.
If there would ever be something like logical transparency in Inkscape (multiply, brighten - as it is everywhere else) - you could have a plugin (like Separate for Gimp), that takes all selected objects, quadruplicates them into four layers, groups, leaves only one color (so that you have the C, M, Y and K separated on four layers) and applies multiply transparency. With tool that changes value of any color into another - you can make separations really easy. And you could trap/flood/rich black/overprint - maybe not quick, but easily. Crappy idea, but if you're "not interested" - there is no other way. And someone will do such plugin sooner or later as soon, as you announce it louder - as it is still mapped in the roadmap. Just put it as a news on the main project page "no CMYK evar" and wait and listen. The sooner - the better.
0.50 Should be ready about 2015, so why not let someone do this job sooner?
pygme - Illustrator may work on EPS/PDF only for me - as far, as they're well supported standards in printing of course, not Adobe's own mods or tweaks as it sometimes happen.
It works with CMYK, spots, overprints, and it don't ruin my job to often - thats what I need.
Saying anything bad about it in this context is pointless - as far, as Inkscape won't support truly CMYK at all.
In my opinion Illustrator is well suited to modifying large, complicated diagrams *only*. I hate it. But it does CMYK+spot without much failures (and Corel does not).
And Inkscape is most creative vector tool I've seen so far. Just not feature complete enough for some Polish mumbling-grumbling guy.
Color management is not the same as CMYK working colors. With color management you make sure that colors are, as far as possible, close by appearance on screen, web or print on different devices. Supporting CMYK colors means you are able to define each color you use in % values and mixed from the CMYK palette.
I used to think that native CMYK was a must for my print work. I was one of those raging designers demanding for CMYK in the IRC channels :-p
Once JonCruz explained me a couple of basics of color management and then I realized that I was almost clueless, and that I was missing so many important facts about color management that rendered my whole "CMYK" work pretty useless.
I was sending my files to the print shop without embedded profiles, I didn't have idea what profiles they were using, I was choosing colors from Pantone Formula swatch libraries thinking they had the right CMYK colors (when they had Lab colors) and lots of other embarrasing mistakes that aren't worth to mention :-p
That motivated me to look for more information about color management and educate myself about late binding workflow (which I found it's also recommended by Adobe and Pantone, go figure!), and now I'm happier because my prints are better, and I'm still using Inkscape and GIMP as my main tools for creative work.
Knowing about this stuff made me understand that I don't need Adobe for my print work. I need to know what I'm doing.
I'm pretty confident that free applications like GIMP and Inkscape will find a smarter way to provide a professional print workflow, better than the early binding workflow that we already know from proprietary applications that "invented the wheel" ;-)
Thanks Jon for opening my eyes, for your work in inkscape and for these good reads in your blog.
Ok, I've read your post, and all the comments and I have one question. Like Łukasz I work in Poland and I used to push my work to both small and large print offices, and all of them wanted me to send my work to them as PDF with colors converted. The question is: how to produce that CMYK PDF with inkscape or gimp? Of course I can import it into scribus, illustrator or corel, and then convert colors on exporting PDF, but I think that's a bit counterproductive. In that case it's a bit simpler just to design in illustrator or corel and not waste time on multiple import/export.uheefoo7Xe4
There supposed to be:
all of them wanted me to send my work to them as PDF with colors converted to CMYK.
My mistake.
Harkonnen2: I live in Argentina and here most of the print suppliers ask the same, but it seems to be more a habit than a need. Some weeks ago I sent a file to a print shop, they asked me for CMYK and when I asked about what CMYK they only replied "just CMYK", and that gave me a clue that they didn't know what they're doing.
I sent them a PDF from scribus with everything in RGB except the black text and guess what: they printed it!
Print providers stress about CMYK because some customers send RGB files with colors out of gamut and obviously they can't be printed (#0000ff, for instance) and then complain because the colors are not the same they saw on screen.
But if you send them a tagged RGB file with colors inside the printable gamut there's no difference and they shouldn't have problems to print it.
Anyway, if you need CMYK values you can specify them in Inkscape with the CMS tab (you need to know which CMYK, of course, and the profile has to be embedded in the document) and open the file with Scribus 1.5 (development version) which will mantain the CMYK values.
Keep in mind that if you overlap RGBA on CMYK values you'll have some separation problems (this is true both in free and proprietary).
Anyway, if I understood it correctly, the idea of this article is to use a different approach, rather than adapting the tools for working with an early binding workflow.
Informative Blog
Visit Us
House painters in surrey
Post a Comment