[Scribus] pantone colors
Fri May 5 12:31:29 CEST 2006
Helmut Wollmersdorfer wrote:
> Gustavo Homem wrote:
>> If so, the missing bit is an algorithm to display them "correctly" on screen,
> That's not possible.
> First, Pantone comes in two versions - coated and uncoated - which are
> very different.
> Second, Pantone does not use the usual pigments. They additionally have
> some pure pigments of blue, red, green and yellow (and their
> combinations), which are out of RGB/CMYK gamut (~colour space).
> Pantone is aimed to order a ink by number, and the ink manufacturer (or
> your dealer) mixes this ink from the Pantone base inks. Then you get a
> can of ink identically to Pantone xy, which you use with an _additional_
> printing plate.
My understanding is that the above is all accurate, and I think it's
important to understand. The best a computer can generally do is use the
PANTONE alternate representation colour to attempt to display the
colour, but it's a best guess only, and probably not a good one. How do
you represent gold ink, a varnish layer, pure primary yellow, a strong
orange, a fluorescent green, or a UV-active ink in an RGB triplet?
You can design a document that uses spot colours on a black and white
screen; it's just harder. You can design with bright pink representing
your varnish layer ... doesn't matter. The RIP doesn't care, it just
cares about the colour name ... and even then, you can print with a spot
colour called "BobsColour" for all it matters, so long as that plate
ends up loaded with the right ink when it comes time to print.
Things get blurrier with smaller digital "presses" that simulate PANTONE
using look-up tables and similar methods. I don't know much about this
directly, but I'll relate what I learned from a conversation with Marti
Maria at LGM. Essentially, these devices are calibrated by the vendor,
working with Pantone, to produce good approximations of PANTONE spot
colours where possible. Internally they see a /DeviceN color, look up
the name in a table, and see if there's a pre-calibrated raw colour
value for that named colour available. If so, they use that colour to
print an approximation (depending on the device gamut, specific colour
being simulated, calibration quality, etc, it could be a good or bad
one) of the requested PANTONE spot. For these devices you need to use
the actual PANTONE names, unless the printer remaps them for you in the
RIP software, but otherwise they're not that much different.
You can't expect to preview a spot colour accurately on screen unless
it's within your display gamut and the alternate representation colour
is accurate (allowing for any required transforms to correct for the
specific output device etc).
On a side note, I personally don't understand how the alternate
representation colours mean much of anything without an associated
colour space. Are they implicitly in the sRGB space, or how are they
supposed to be treated when converting to XYZ/L*A*B color in preparation
for display correction?
Somebody yell at me if I'm wrong here, please.
> If your target is the usual 4-colour/CMYK process, then you should
> define your colours in CMYK-values (or raster percentages). Never use
> Pantone in this case.
Note that even then, your results will vary. Your job will come out
looking different depending on what press it goes to, since (10,20,0,40)
(for example) looks different with different inks, paper, print
processes, presses, and so on. You would need to allow for biaes in your
specific press, have the printing done according to a pre-corrected
proof (automatic or hand matching), or generate output that considers a
device colour profile. If your printer can handle it, my understanding
is that PDF/X-3 is the best option, since it tells them what your
colours are, and lets them use their own press profiles to convert the
job into colours suitable for their press. Failing that, outputting a
CMYK PDF using a colour profile for their press ought to do a pretty
I doubt you can ever get as good a result as by hand-tuning CMYK values
for a specific output device, but unless you do a LOT of printing with
that one company, press, media, etc, you're never going to get that
working well. Even then, it's a lot of work. I should know, the company
I work for has been doing that for five years, and we're moving to
PDF/X-3 now in an attempt to ensure more consistent output.
> Helmut Wollmersdorfer
> Scribus mailing list
> Scribus at nashi.altmuehlnet.de
More information about the scribus