[cairo] Creating CMYK and spot colors using Postscript backend

[Craig Ringer]

Bill Spitzak wrote:
> I don't think this is as complicated as people are making out.
> 
> Worrying about ICC profiles, etc, is wrong. The backend *can* use them,
> or not. What is true is that the Cairo must pass all these color types
> through, with NO interpretation, to the backend. The backend can do
> whatever it wants, including calling some simple converters that are
> provided by Cairo.

I'd agree with that, except for the "simple converters" part (see
below). Also, the colours still need to be able to have profile
information associated with them in order for the backend to be able to
use colours in spaces other than its own.

> The simple converters provided by cairo will turn CMYK into RGB using
> the 1-c, etc style of conversions. THIS FUNCTION IS FIXED, it never ever
> ever ever changes, no matter how many ICC profiles or color calibrations
> your computer has.

I don't think that's a good behaviour. Such conversion functions
generally produce really poor results, and really aren't very useful.
IMO it'd be better to simply fail to convert the colour and report to
the user that the surface only supports RGB colours, and no conversion
to RGB was possible from the specified colour. Users of Cairo really
should not be mixing colour spaces without some sort of colour
management in any case, and giving them the impression that this might
work and produce useful results is probably not helpful.

People who would be happy with the results of such a simple fixed
converter probably shouldn't be using mixed colour spaces at all, and
are probably confused as to what really happens when you try to mix
colour formats and spaces.

If such a simple converter is provided at all, IMO applications need to
be able to set Cairo's state so that use of the simple converter causes
drawing to fail with an informative error.

> A backend can of course implement it's own conversion
> from CMYK to RGB, or keep track of 4 or more channels itself (and thus
> also convert RGB to it's own CMYK).

I expect backends would want to build a collection of shared conversion
operations, since there would otherwise be quite a bit of duplication of
code and effort.

The Cairo core would still need to provide a way to pass ICC colour
information through from the public APIs, such as as an additional
member of cairo_colour_t . I doubt it's practical for backends to get
ICC colour information from some outside channel, as they'd really need
it to be associated with the colour or pixmap image.

> The simple converter provided by cairo will turn a "spot color" into
> CMYK by throwing away the spot color name.

So long as the documentation for the function strongly indicates that
this is only ever correct if the surface does not support spot colours,
and there's a way for an application to get a warning from Cairo when
this conversion is used with a particular surface, that seems sane.

It should certainly be possible for applications to absolutely prevent
spot colours from ever being converted, and have any such attempts cause
rendering to fail and report an error to the application. There are
times when silent conversion of a spot colour is an absolutely horrible
problem that really must be detected.

> Then the CMYK color is
> converted as above. A backend can instead try to remember the spot
> color, or make it another channel, or (most likely I think) only use it
> directly if it is being set as the source color (drawing a spot color
> into another surface and using that as a source would produce the cmyk
> color.

If I've understood what you're saying correctly, that sounds pretty
reasonable so long as apps have a way to find out if spots are being
converted.

When spot colours are being used, rather than just a pre-set CMYK value,
it's usually because they're intended for output as a separate channel
(eventually press plate) or to a calibrated device that can internally
do an accurate conversion of the colour name to the output values
that'll produce the desired colour for that particular device.

An RGB pixel-oriented backend would want to use a conversion operation
to obtain the RGB preview value associated with the spot colour. It'd be
desirable for applications to be able to detect when this was done, but
since they're sending a spot to an RGB pixel-oriented surface, they
might be reasonably expected to figure it out for themselves.

PS and PDF backends would want to preserve the spot colour exactly as-is
as a named colour. Any use of the preview colour or any conversion of
the spot would need to trigger a warning, or even be
application-configurable to be an error. Silent conversions by the PS or
PDF backends would be *BAD*. In conversion terms, it can also be
desirable to have a pure-RGB pre-converted PDF and the same for CMYK -
but it's not unreasonable to make this the application's problem.

A CMYK pixel-oriented backend would probably do what you said, and use
the CMYK preview value of the spot. It'd need to emit some form of
warning when this was done. If the backend supported more than 4
channels, it might instead be configured to output the spot as an extra
channel as you suggested, but I expect need for this would be pretty
rare. In fact, since Cairo doesn't have any CMYK pixel oriented backends
and probably won't unless someone finds a need for one this isn't much
of a worry for now.

--
Craig Ringer