[cairo] Spot colors (and CMYK)

[Andrew Cowie]

On Wed, 2010-02-17 at 12:46 -0700, Chris Murphy wrote:
> But if you disallow CMYK, or K only, then people cannot express an
> intent to print K only text on a device that will produce lawsuit
> worthy output if it's not printed as K only. Text needs to be
> specifiable as /devicegray or /devicecmyk as well as the fact it is
> text.

I often find myself surprised by is how old PDF is; it was originally
for getting artwork from graphic artist & layout people through
pre-press to printer. Taking the film out with computer-to-plate
accelerated the process, but didn't fundamentally change anything.

Using on-screen readers such as Acrobat Reader and Evince & other xpdf
friends is actually a relatively recent thing. That they enabled .pdf to
become an electronic paper format is really cool.

But embedding enough information, *especially* colour information, so
that a print house would be able to first proof and then faithfully do a
large run of an entire book, magazine, packaging, poster, etc on
{offset, flex, gravure, whatever} equipment was what PDF was originally
about, an in the professional world it is what it is still all about. If
we want our software to be able to compete with the well established
proprietary toolchains, then we need to handle this level of
sophistication.

Clearly we have a number of viewpoints in this thread; personally I'm
more aware of the output-to-paper side of things because reports,
illustrations, and promotional materials are important to just about
anyone doing business work, but it is interesting that at least one
person is arguing from a perspective in the visual effects world; in
digital video there's no output to print so I can see how an *RGB-only
model would appeal.

People tend to miss the point that looking at a PDF on-screen is not
proofing — well, not unless you've got an extraordinarily sophisticated
workflow and *really* good display hardware. The fact that lots of
customers have no choice but to look at pre-press work on-screen this
way doesn't really mean they're proofing; at best they're checking
layout, and trusting their pre-press house to get things like colour,
registration, and imposition right with the printers. In a way on-screen
readers don't have to worry about colour (I mean, it'd be nice, but)
because everyone "knows" the colour on screen is going to be wrong.
Shame really, but there you are. Meanwhile the pieces of any graphic
arts workflow had better be getting it right under the covers, because
by the time it gets to the printer it's getting expensive to change
anything.

And silly as it may seem, being able to specify K only is (as one
example) really important; right now Cairo outputs 100% × CMY and I got
laughed out of the room when I brought .pdf output from our stack into a
printer for proofing. The problem wasn't the graphics layer, but that
the entire application stack — of which Cairo is just a part — wasn't
able to give me a way to specify the colour usage.

Hopefully we'll find a way to allow the users of Cairo (ie, application
developers) to instruct a backend to produce specific results. People
have presented strong arguments that an sRGB-only API is not the way to
achieve that, but I'm not clear what the alternative API would look
like, so it's hard to compare.

Cairo is a beautiful drawing library, and you can feel the tension that
this discussion creates in the minds of people (ie, it's authors :)) who
consider it a vector graphics API. But if we want to use it to draw to
anything that people can use for "professional" (I hate that term
because it's so pejorative, but what else do you want to call it?)
quality print output [ie anything other than black & white to a laserjet
printer] or broadcast quality visual effects [ie anything above home
video on youtube], we'll need to find a way to address the colour space
question.

It would be perfectly reasonable if someone were to say "that's not what
Cairo is for", though if that was the decision, I'm not sure where else
we'd go.

/me loves Cairo

AfC
Sydney


-- 
Andrew Frederick Cowie

Operational Dynamics is an operations and engineering consultancy
focusing on IT strategy, organizational architecture, systems
review, and effective procedures for change management: enabling
successful deployment of mission critical information technology in
enterprises, worldwide.

http://www.operationaldynamics.com/

Sydney   New York   Toronto   London
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.cairographics.org/archives/cairo/attachments/20100218/1ab5d758/attachment.pgp