[cairo] RFC the idea of n-plane color support

[Ross McFarland]

Bill Spitzak said:
> On Saturday 30 October 2004 07:15 am, Ross McFarland wrote:
>
>> the most common case with Postscript (which is almost always bound for a
>> printer) is CMYK which accounts for the majority of driver generated
>> jobs. text is the biggest reason for that, you have to use pure black
>> for black text or otherwise the slightest mis-alignment between color
>> planes will make the text blurry and hard to read due to color shifts
>> and such.
>
> Just to note that the "blackest" black is done by printing all 4 colors, and
> this is certainly wanted for a 0,0,0 in a color image, but that is not
> necessarily what is wanted for 0,0,0 in text. So his point is that the useful
> volume of colors for the printer has 4 dimensions and thus no mapping from
> sRGB will get all the desired output.

this is kinda true, but not exactly. some printers black's get darker when a
mixture of CMYK is used, but not all (depends on the inks/toners.) other times
the amount of ink toner is limited by the ability of a fuser to melt the toner
or the fact that too much ink will saturate the page with liquid to the point
of destruction of the paper. i'm not sure any printer inkjet, laser, or
otherwise will put down 400% coverage due a combination of the above and other
reasons a couple hundred percent is a much more common limit.

> However it may be better to have the printer analize the image. For instance
> black surrounded by white would only print the black ink. Obviously this
> would solve the black-text problem for many more programs, such as ones
> unaware of the CMYK interface. It seems to me that to do this the backend
> would have to store rgb so the analysis can be done last. This may mean that
> the backend must support both formats, or that the CMYK interface is a bad
> idea.

this falls into one of the million things that has been tried to parially
solve the problem but doesn't end up working that well in practice. for
starters black text can be printer on any amount of color background and still
almost always needs to be pure k ink/toner.

i'm not talking about a cmyk interface to cairo being used by apps. although
at times it could be benificial to let the apps talk in cmyk, this is a
commonly used ability of apps like acrobat  pagemaker, and illistrator when
working with a postscript printer. they normally write their own custom
postscript to get around the fact that the windows GDI doesn't let them talk
in CMYK. page layout programs using cairo would be forced to do something
similar (avoid the cairo pdf/ps backend) to get a similar level of control.
this is a much more complicated issues that arises out of the same problem of
control over which toners are used when, but it's wholey seperate from my want
of an arbitrary color pathway through cairo's drawing code.

-rm