Re: [Inkscape-user] spot colour
The discussion around spot colour largely misses the point as I see it. As a professional graphic artist I think its an important thing to have clearly understood.
Colour support has become my #1 problem with using inkscape at work. Well, that mixed with the fact of the difficulty of getting editable artwork to work the same in illustrator (just for setting up separations for output).
LittleCMS doesn't matter particularly as the answer to the original question from Terry Brown. Printing as SPOT colour, means output separations for named colours individually, not mixed as CMYK, RGB, LAB or anything else.
Example:
- Pantone 872C is a gold metallic ink (can't be accurately mixed in other systems). - On spot colour output you want a separation of solid black ink (to make the printing plate), labelled Pantone 872 (for the ink that is applied). - To approximate it on screen you want specific RGB values - To approximate it web-safe you need some other RGB values - To approximate it on desktop printer you need some CMYK values
Nasty workaround: =============
I started doing graphics in the beginning of the desktop publishing almost 20 years ago, and there was time like 90-91 where you had to abuse the CMYK separations to get spot separations out of illustrator and freehand:
- re-color your artwork before sending to the printer, - so 'Pantone 872C' became cyan (for instance), and - make sure the printer had clear instructions replacing cyan with Pantone 872C
Changing applied colours like that in inkscape is laborious for complex artwork. Its probably less work than the suggestion in this thread of setting up layers for the various colours, exporting them individually and manually aligining the separations later in other programs.
The problem? ==========
I think the reason this is not addressed in inkscape, is the way that colors are stored and used.
We can use a palette to apply a color. Later we cannot change the palette - and even if we could, it wouldn't change all instances where that colour is applied.
The established solution: ==================
Illustrator has an additional concept of swatches - where the colour properties of objects are linked to a swatch object. Swatches can be changed, changing all objects/lines/fills/gradientstops that reference them.
This is extremely useful in complex illustrations where you might have several colours that mean things, but need to adjust them later in the process.
A spot colour needs to be defined like a swatch, so that the one definition can be used identically across many different objects, and later used as a separation.
That also allows artwork to move between colour spaces, as each swatch can have a representation defined in each colour space.
That is the real value that the downloadable profiles and swatch libraries provide -- the ability to match output from different devices eg. screen (RGB), web-safe (RGB), inkjet (CMYK),web offset lithography (CMYK with colour profile) and spot colour reproduction.
On Jun 3, 2009, at 10:49 PM, Mathew Oakes wrote:
I think the reason this is not addressed in inkscape, is the way that colors are stored and used.
We can use a palette to apply a color. Later we cannot change the palette - and even if we could, it wouldn't change all instances where that colour is applied.
Base changes have been in for a while (icc-color as of 0.46), and live-edit palette work has already gone in for 0.47
On Jun 3, 2009, at 10:49 PM, Mathew Oakes wrote:
Illustrator has an additional concept of swatches - where the colour properties of objects are linked to a swatch object. Swatches can be changed, changing all objects/lines/fills/ gradientstops that reference them.
This is extremely useful in complex illustrations where you might have several colours that mean things, but need to adjust them later in the process.
A spot colour needs to be defined like a swatch, so that the one definition can be used identically across many different objects, and later used as a separation.
That also allows artwork to move between colour spaces, as each swatch can have a representation defined in each colour space.
That is the real value that the downloadable profiles and swatch libraries provide -- the ability to match output from different devices eg. screen (RGB), web-safe (RGB), inkjet (CMYK),web offset lithography (CMYK with colour profile) and spot colour reproduction.
This is a bit bad, as it leads people to corrupt the meaning of the term "swatch".
see "What is a 'Swatch'?" http://codewideopen.blogspot.com/2008/03/what-is-swatch.html
and the wiki page on "Swatch Book" http://wiki.inkscape.org/wiki/index.php/Swatch_Book
SVG also has the concept of a "style", that leverages CSS. Also styled colors in SVG can have a icc-profiled color to give the portable colors.
On Jun 3, 2009, at 10:49 PM, Mathew Oakes wrote:
LittleCMS doesn't matter particularly as the answer to the original question from Terry Brown. Printing as SPOT colour, means output separations for named colours individually, not mixed as CMYK, RGB, LAB or anything else.
LittleCMS actually does matter.
It gives support for *previewing* output results, for detecting out of gamut colors, and even for using named color icc profiles. The latter is probably the primary way to reliably and portably denote spot colors, but SVG hasn't integrated direct use of them yet.
A functional work-around would be to have an icc profile with a single number input, and that does an effective index into a set of spot colors. A bit strange, but should work with Inkscape 0.46 as it was released.
On Thursday, June 4, 2009, 10:02:35 AM, Jon wrote:
JAC> JAC> On Jun 3, 2009, at 10:49 PM, Mathew Oakes wrote:
JAC> LittleCMS doesn't matter particularly as the answer to the JAC> original question from Terry Brown. Printing as SPOT colour, JAC> means output separations for named colours individually, not JAC> mixed as CMYK, RGB, LAB or anything else.
JAC> LittleCMS actually does matter.
JAC> It gives support for *previewing* output results, for detecting JAC> out of gamut colors, and even for using named color icc profiles.
I agree that ICC named colours is the correct way to go here.
JAC> The latter is probably the primary way to reliably and portably JAC> denote spot colors, but SVG hasn't integrated direct use of them yet.
In fact, SVG does have named colour support http://dev.w3.org/SVG/modules/color/master/SVGColor.html#named
JAC> A functional work-around would be to have an icc profile with a JAC> single number input, and that does an effective index into a set JAC> of spot colors. A bit strange, but should work with Inkscape 0.46 as it was released.
JAC>
On Jun 5, 2009, at 1:55 PM, Chris Lilley wrote:
I agree that ICC named colours is the correct way to go here.
JAC> The latter is probably the primary way to reliably and portably JAC> denote spot colors, but SVG hasn't integrated direct use of them yet.
In fact, SVG does have named colour support http://dev.w3.org/SVG/modules/color/master/SVGColor.html#named
Well...
I'd say "may" or perhaps "may soon have"
That is from:
SVG Color 1.2, Part 2: Language W3C Working Draft
1.1 was also going to have <solidColor> :-)
On Jun 5, 2009, at 10:35 PM, Jon A. Cruz wrote:
Well...
I'd say "may" or perhaps "may soon have"
That is from:
SVG Color 1.2, Part 2: Language W3C Working Draft
1.1 was also going to have <solidColor> :-)
Oh, just to be clear...
Once things are set with 0.47 we'll be getting as much done here as possible. There is the GSoC project for color management and once the draft there hits the point where implementors are encouraged to move forward then we'll implement the named colors.
participants (3)
-
Chris Lilley
-
Jon A. Cruz
-
Mathew Oakes