Inkscape Does Support CMYK

While some are mislead by the fact that Inkscape does not (and probably should not) support raw or "generic" CMYK, it does in fact support working with true CMYK for print support. The key factor is that Inkscape only supports real CMYK work, and not "pretend CMYK." In and of itself "CMYK color" does not mean anything specific. It turns out that "RGB color" is also meaningless as far as specifying an actual color goes, but the variances are usually not as strong. To get accurate RGB color, one needs to specify *which* RGB to use. SMTP television values, Adobe RGB, Wide Gamut RGB, sRGB, etc. For experience on the Internet, people usually don't realize that there is an implied colorspace of "sRGB" used for tools, browsers, etc.

In a similar manner, Inkscape needs to be given a *specific* CMYK colorspace to work in. In fact, Inkscape (and SVG itself) can support a document with several different colorspaces at once, including mixing multiple different CMYK colorspaces alongside RGB colorspaces. This could be useful for cases such as when a graphic designer is creating artwork for some brochure that will be printed with cutaways and different paper types. Or it could apply to a case where different printers are used for different parts of a job. (Figure 1 shows what appears to be the same colors)

However an fairly common use case is where one might create a document to be printed mainly in CMYK, but with one or more spot colors, such as Pantone, Toyo, HKS, etc. colors. In this case, some elements of the artwork can be marked with a specific target CMYK profile, while the elements to be done in a spot color can be specified with a named color profile supporting the type of spot color (for SVG 1.2) or perhaps even with simple sRGB equivalents. Then when things go to a service bureau to be run the CMYK elements can go to a four-color print and the spot colors can go to custom plates per ink. (Figure 2 shows that the colors are actually different)

So how does only get to "real CMYK" in Inkscape? It's actually fairly simple. First at least one CMYK profile needs to be added to the document being worked on. That can be accessed in the GUI through the "Color Management" tab on the document properties dialog. Once at least one profile has been added, the color pickers in the Fill & Stroke dialog can be used to pick colors in that colorspace via specifying the ICC profile. In the past one needed to use the CMS color picker, but with Inkscape 0.48 the other color pickers such as the "CMYK" one will attempt to preserve values. (Figure 3 shows that the exact same CMYK numbers were used)

The main problem left is that even though true CMYK values are stored in the saved SVG value, using those values is now a bottleneck. Printing directly from Inkscape will flatten things to sRGB, and even PDF export will not yet preserve the CMYK values However, other software can read and use those values. Recent versions of Scribus will read in and preserve ICC colors including CMYK, and will happily save high-quality print-ready PDF output. (Figure 4 reveals the difference in RGB and visible colors that result from using two different CMYK profiles)

Read more!

"CMYK" is Meaningless

For anyone working with print there is one key principal to keep in mind: "CMYK numbers" are meaningless. Far too often artists are lured into "working in CMYK" without actually understanding what it means, and fall into the trap of believing their work is more precise when the exact opposite is true. Saying "50% Cyan" does not actually specify any color, and will most likely result in many different colors being produced. The subtle yet critical difference between "untagged CMYK" vs. "unspecified CMYK" is the bottom line that will mean the difference between success and failure.

CMYK is a type of colorspace, but in and of itself does not actually specify anything. It just tells how one can define a specific colorspace. To actually make sense a specific device (either real or theoretical) needs to be targeted. Once the specifics are involved, however, working in a specific CMYK is a very helpful thing. It is good to try to not get caught up in distraction of focusing on the "how" of things and instead look to the "why" of doing things.

In this case, the distracting "how" is people "working in CMYK" while the "why" they should be focusing on is reliably creating and controlling color. Instead of an artist getting caught up in saying "I need to get exactly a 50% saturation of cyan ink onto the printing plate at this point", they need to shift to say "I need to get this point of the final print output to be exactly this shade of color." That is not to say that an artist should never be concerned about CMYK numbers and plate separations, but rather they need to keep in mind that the ink details are merely a means in reaching the ends of the final print. (There is one main exception to the focus on raw CMYK, but I'll cover that later)

So although 'raw CMYK' numbers might be meaningless and produce randomly shifting results in completely unpredictable ways, CMYK values in a specific context normally give very precise and controlled output. Be wary of anyone asking for or providing "generic CMYK". However, specifics such as "SWOP v2 CMYK" will allow for fairly exact control and results. If someone says "CMYK", the response should be "which CMYK?"

What does this all mean in practice? If one is producing artwork that will go to print, getting specifics nailed down is critical. When working with a good print house, they will provide either specific profiles for the output that will be run, or will say which industry standard profiles they will work from. The artist provides content targeting the specific CMYK profile and then the printed results comes back with the exact appearance that was intended. The print house gets this generally specified input and then does a specific conversion from what the artist supplied to the measured control needed for the specific press and the actual paper with that days inks and the current temperature, humidity, etc.

When such a good workflow is used one can get reprints run at any time later on and the output will match what was printed the past week, month or even year. Thus there is no need for the time nor the expense of multiple tweak-and-reprint runs to end up with acceptable results.

On the other hand, if a small shop is used that employs no color management in their own workflow, the burden falls squarely on the artist/customer to come up with ways to get consistent and desired output. Sometimes the print shop will provide some target profile, but make no guarantees as what the resulting run will look like.

This is the point where most will just think they're working directly with raw CMYK and just need to tweak things over and over until they are close enough. That's actually not what they should be doing. The critical need here is to understand that they are not working in "generic CMYK", but that they are working to a very specific CMYK. They really are working in "CMYK for fliers printed at the corner press". Sometimes that color will be consistent over time, but more often even that will vary from week to week or from day to day. If the artist was smart, he would have created his own profile for the local print shop and will work in an industry standard CMYK and convert to the specific local shop CMYK for delivery to them. He also should have done some simple calibrated output (perhaps in the margins of his run) so that if (or more likely when) the local print shop gives different colors for the same numbers he can call them on it and get things corrected.

For a shop with a good relationship, the artist can use his own management and tracking to get the print shop to correct their output. Some small shops might not even be employing much in the realm of color control but can happily match output to a reference proof they get handed along with the files for the job to be run that day.

Finally in the case were the local print shop will give varying results and no help for color matching we reach the situation I mentioned where actually sending raw CMYK values is desired. However the reason for sending out a file with raw CMYK that is intended to go exactly to the end plates is in creating a test target output for measurement so that the artist can create his own target CMYK profile. The artist can send over a raw file to get a test output print, and then measure that test print. He then converts the real job files to using that locally created profile and sends the adjusted art files over to be printed. The net result is better output with lower costs due to avoiding reprints, etc. (so "raw CMYK values" should really only be used for printing test targets)

This last case helps illustrate the difference between "untagged CMYK" and "unspecified CMYK". The artists sends over art files that are not tagged with any embedded ICC profiles. However these are not raw nor "unspecified" CMYK values at all. Rather they are CMYK numbers in the specific profile that the artist himself has created to describe the characteristics of the local print shop. Although the files are not literally tagged with the profile, they have been created with an explicit ICC CMYK profile specified in the artists workflow.

And the bottom line? Be specific and you will save both time and money. And end up with happier clients.

Read more!

Inkscape should NOT "support CMYK"!

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)

Read more!

Color talk at linux.conf.au

I just got word today that the videos from linux.conf.au 2009 started showing up online, and mine was among the first set. The video is up in ogg, and should be nice and open, so grab it and check it out if you might have an interest. There's no interpretive dance, but there is juggling. The target for the talk was fairly broad, so as to be helpful to as large a group as possible.

Unfortunately, the other Inkscape presentations have not gone up yet, so we have to wait a little longer for the complete experience. Andy did a nice LPE talk, and Donna had a good intro class. I think the main problem with the latter was that there were more interested people than space for hands-on in the talk. Then again, that's usually a good problem to have, since it shows good interest.

You can download the video for "Why Color Management matters to Open Source and to You". I did get them a copy of the slides (which include full notes), but those don't seem to be online quite yet and are now up. The abstract for the talk has been online, so that's a handy summary to check and see if the video might be of interest.

Once more finish getting posted, I'll try to get a summary of some of the more interesting and/or useful up. Then again, they are good resource and are worth checking out overall.

Read more!