[Scribus] pantone colors

[Craig Ringer]

Helmut Wollmersdorfer wrote:
> Gustavo Homem wrote:
> 
>> If so, the missing bit is an algorithm to display them "correctly" on screen, 
>> right?
> 
> 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 
good job.

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
> http://nashi.altmuehlnet.de/mailman/listinfo/scribus