This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new!

Spot Colour

Posted by: Anonymous Coward on November 23, 2005 10:30 AM

First, regarding the GIMP, the real issue has mostly been the lack of CMYK support and colour management. Spot colours don't really make that much sense in a bitmap image editor anyway - they're mostly used in vector graphics and desktop publishing.

On spot colours, I think it's worth re-emphasising Peter's point: Spot colour support is not the same as PANTONE support.

Here's my take on the matter:

It's actually generally possible to produce a 1 colour job in an application with no spot colour or PANTONE support. You simply output it as greyscale, and tell your printer the PANTONE ink number to use. After all, on the press all it means is that they use a different ink instead of black.

Extending from that principle, if your application supports spot colours but has no built-in support for PANTONE, you can still make (eg) a 2 colour ("1 spot") job. You enter two new spot colours called, say, "my dark red" and "colour 1" into the application's colour list and design with them. When submitting the job, all you need to do is tell the printer which inks to use for "colour 1" and "my dark red", probably be speciying PANTONE ink names. If you name the colours by their PANTONE names, then you usually won't even need to tell the printer that much.

That's what many DTP users did until very recently. Here at work, the users still enter PANTONE colours into the colour picker by hand when they want to use a colour, and that's with QuarkXPress on Mac OS 9. That was the long-standing mainstay of prepress for a very long time.

That's also why Franz's addition of spot colour support in Scribus 1.3 is so darn cool. I'm going to be doing a few spot colour house ads for my employer, the POST Newspapers (Australia), in Scribus soon, which is an exciting thing to be able to do.

Anyway, it doesn't hurt if your application has a built-in list of PANTONE spot colours, but it's not really necessary. I only understood this recently. All you really need is spot colour support, and you can often get away without that for one-colour jobs. What you really need is the swatch book, as this article has so clearly pointed out. That book contains samples of the colours, each with a PANTONE name and a colour code that you can enter into your application, and it's that book that costs the money.

A spot colour in a DTP app consists of two things - a colour name, and a display tone. The name is what the printer uses to identify the plate - and if you've used the name specified by a major ink matching system like PANTONE, they can probably just pick the right ink without needing to be told anything extra. The display tone tells the application what colour to use to approximate the real spot colour ink when working with pure RGB or CMYK colour spaces. It's not actually used when the job goes to press. Colour management is useful for making this "display tone" better approximate the real colour you'll get in print, but that's all it is - an approximation to help you when designing, proofing, etc.

Nothing stops you making a spot colour that shows up bright green in the application, and giving it a name that suggests the use of a deep red PANTONE spot ink, or telling the printer to use a metallic-looking silver ink.

It's also worth noting that spot colours can use other ink schemes. You could negotiate with your printer to mix inks to your specifications, or you might have inks from a different supplier that you wish to use. If that ink maker has supplied you with a swatch book then you get the same "looks the same in front of me as in print" effect as with PANTONE, though you probably have a much smaller range of colours to choose from.

So long as the printer knows what inks to use and you know how they'll look, you're all set.

Craig Ringer


Return to Pantone and free software