[Openicc] Creating CMYK and spot colors using Postscript backend

[Graeme Gill]

Craig Ringer wrote:

> At this point I don't think anybody is expecting proof quality output,
> but leaving room for the possibility would be ideal, since a
> tiff-separation backend or something like that would indeed be useful
> for some users.

It's not just about proofing quality output, it's about any sort
of sensible output. If a multiple PostScript job depends on
overprinting tints of spot colors, you need a rendering model
that understands this to get something that represent at least
roughly the, intended output. You may not want to be able
to process this type of input though.

> For one thing, there are potential legal problems surrounding access to
> tables for widely recognised spot colour libraries like PANTONE, and
> some of those colours can't really be usefully represented in commonly
> used output colour spaces anyway. So long as they can be output as
> correct named colours in PS/PDF, and the alternative representation used
> for other targets, I'd think that would be fine.

In my former job I spend some time working around this issue. The
solution we adopted was to reverse engineer the spot color library
format used by a vendor that sold licensed versions of the Pantone
library as part of one of their products, and then purchase copies
of that vendors product for each copy of our product we wanted supplied
with a Pantone library.

The same might be possible for Pantone products like
Pantone Colorist: <http://www.pantone.com/pages/products/product.aspx?pid=96&ca=3>,
so that anyone keen about using Pantone colors can simply buy the library
from Pantone.

The other more devious idea was to create a spot color library that
had a collection of colors of sufficient size and resolution that
there was at least one color close to each Pantone color,
and then index the spot color library with numbers that just
happen to be the hash value of the corresponding Pantone
names. Since the Pantone names were not copied, and the selection and
arrangement of the spot colors is also not copied from the Pantone
set, it should (in theory) avoid any copyright infringement.
You'd probably need a small army of lawyers to fight off
Pantone in court though :-)

> Interesting point. It sounds like potentially Cairo could in fact handle
> accurate spot colour conversions into the target colour space, if it had
> device independent representations of those spots available.

Right. Standard spot color library formats are ICC, and GretagMacbeths CxF.

> While I doubt Cairo could ship such tables, applications could provide
> them, or could flag the alternative colour associated with a spot as
> being such an accurate device-independent representation of the spot
> rather than just a preview.

You either need to arrange that the application adds the
device independent color value to the spot color name, or
the rendering system needs to have its own spot color library
to translate the name into a color. The latter is necessary
for good color reproduction of PostScript or PDF spot colors,
since the fallbacks that come with those formats are not
necessarily accurate (ie. process fallbacks rather than the
actual spot color).

> That makes sense, and puts more weight behind retaining colours in their
> original (tagged, mixed-space) forms as far through Cairo as possible,
> so backends can make the best decisions about what to do with them.

That's one way of doing it. The other (more rendering system) way
of doing things is to convert everything to a rendering color
space plus an intent tag that retains the "it's a text object/pixel"
or "it's an image object/pixel" type information, so that when the
rendering colorspace is translated to the output device space, the
appropriate color conversion can be used. This is obviously not
something you'd want in an editing system, or a rendering system
that is designed to faithfully reproduce CMYK values, but it is
something that might be useful in a system that is intended
primarily for rendering RGB color graphics output.

cheers,
	Graeme Gill.