[cairo] Creating CMYK and spot colors using Postscript backend
craig at postnewspapers.com.au
Tue May 15 22:02:25 EEST 2007
Bill Spitzak wrote:
> In general, throwing errors or producing no output makes graphics
> programs extremely fragile and bug-prone and should never be done if at
> all possible. Another example is that poorly-formed UTF8 should draw as
> many glyphs as possible and must always draw a box or something for
> every erroneous byte.
In both those cases, as an application developer I'd be happy if the
graphics code produced output (even bad output) - but *told* me that it
was incorrect. However, it'd be extremely frustrating to have silent
failures and mis-rendering.
If rendering doesn't fail, applications need some other way to detect
and diagnose problems with the output. In fact, this is probably better,
since Cairo could then:
- Report multiple different problems if they exist; and
- Provide useful details about the problem(s)
... where just failing to render isn't overly helpful or informative.
So, in short, I think you're right that it's best to avoid failing and
instead produce a "best effort" result. However I do maintain that it's
better to fail to render than it is to silently and undetectably produce
bad output - which is exactly what such a default cmyk->rgb converter
would do unless some form of logging was in place. It's really not cool
to do something dodgy and *not* provide a way for the application to
discover that's happened.
It's also probably not reasonable to expect Cairo API users to
anticipate all situations that might produce bad output. Asking them not
to send bad UTF-8 is probably sane enough, since it's fairly easily
verified - but it'd still be nice for apps to be able to find out if
this has happened. It's harder for applications to make sure there is no
situation that will cause poor quality CMYK conversions to be used, or
cause spot colours to be discarded. Apps really need some way to find
out if this is happening.
More information about the cairo