[cairo] Creating CMYK and spot colors using Postscript backend

[Craig Ringer]

Markus Meyer wrote:
> Hi Craig,
> 
> thanks for this long and informative message. I agree that there are
> many issues to consider when other color spaces than RGB are introduced.
> However, I see a chance that stuff is being complicated too much and
> that this will ultimately lead to no implementation taking place at all.
> 
> I do think that introducing other color spaces (CMYK, spot colors, CMYK
> with spot colors, HSB, whatever) can make sense without color
> management. It is my understanding that Cairo uses a generic structure
> to paint on a surface which is called a "pattern". This "pattern" can be
> a solid color (currently RGB only), a bitmap or whatever. It should be
> no problem to extend this in a first step to allow solid CMYK colors or
> spot colors as a "pattern". (Actually, this is all I need in my
> application, so I'd be happy with just that.) This has nothing to do
> with color management per se. Although it might not make sense to mix
> color spaces within one surface, it is perfectly reasonable to expect
> from the application not to do so.

That makes sense.

I'd argue that an appropriate error handling mechanism is needed to let
Cairo report "you did something nonsensical and insane" with enough
detail that the app author can figure out what they got wrong, though.
One would be needed anyway to handle things like doing stupid things
with spot colours, and to warn that a spot colour could not be output,
so the CMYK or RGB preview colour was used instead.

> Later, when support for other color spaces has stabilized, one can
> always go on and allow attaching color profiles to surfaces, implement
> automatic conversion between different color spaces (using some kind of
> unified internal color space) and so on. However, I should always be
> able to say "I want that color" and have that color come out exactly as
> specified in the resulting PDF/PS/SVG or whatever file without any
> conversions and rounding errors.

Again, that sounds reasonable. I guess because of my colour managed
printing background I tend not to care too much about minor rounding and
conversion issues, since I've seen that for the kind of work I do the
end result is the same. However, I recognise that's not true for
everyone, or at least that there's a definite demand for exact
passthrough of CMYK values.

In fact, if you're using "fake" spot colours ("Print CMYK (40,20,0,10)
as PANTONE#337) exact CMYK value pass through is critical, but as far as
I know that's fallen into disuse even in the exceptionally change
resistant world of printing. I've never seen examples of other uses
where preserving exact CMYK values is necessary, but accept that the
demand for being able to do so is so high that apps really must support it.

There are situations where an operation is requested that is just not
possible without a colour space conversion, though. If there was no
colour profile information associated with the colour, such a situation
would be an error condition where rendering couldn't usefully continue,
whereas (once such support exists) if you did provide colour profile
details Cairo could convert the colour to the required space and keep
rendering. That said, except for rendering to surfaces that don't
support spots or CMYK at all, I don't know if it's possible to encounter
such situations until multiple colour space support is expanded beyond
using only patterns.

Doing things the way you're talking about (preserving colours untouched
as far through the rendering process as possible, and using patterns for
spot colours and "exact-value-only" CMYK colours) would make it possible
to implement the ultra-minimalist CMYK & spot support you're talking
about in a way that could be built upon and enhanced later to get more
complete and generally useful multiple colour space support. So there'd
be no risk of a full multi-colour space feature existing in parallel
with a minimalist one that worked completely differently. It's also the
most flexible way to do things in the long run, and solves problems like
preserving greys and exact CMYK values that converting everything to one
colour space won't help with.

However, once the interfaces added for your CMYK + spot support are
public, my understanding is that they must be maintained for
compatibility. Given that, it probably IS worth thinking about future
needs to expand multiple colour space support when designing the details
of the public aspects of these interfaces.

--
Craig Ringer