[gs-devel] Uncolored patterns with antialiasing (bug 688933 fix)

[Konstantin Shemyak]

Planning to fix the bug I've reported (688933), got to a place
where advice from more experienced GS developers is appreciated.
Bug is filed against v.8.54, and line numbers refer to that version.

The interpreter exits with code 255 when running with anti-aliasing
(GraphicsAlphaBits = 2 or 4) on an uncolored Postscript pattern.
Shortest example is in the GS bug database 
http://bugs.ghostscript.com/show_bug.cgi?id=688933, attached as
http://bugs.ghostscript.com/attachment.cgi?id=2583&action=view.

The error is toggled in gxpcmap.c:353, 
function pattern_accum_get_bits_rectangle(), as for any
uncolored pattern padev->bits == NULL. The comment in the code
acknowledges the fact that padev->mask should be used for filling
the 'unread' argument, and no error should be returned.

The latter function is called by gx_default_get_bits(), which has no
option to inform the caller that some pixels are unread. To my
understanding, the signature of this function should be changed to
allow for unread pixels, and then it has to be overloaded for
pattern accumulator device to possibly fill this parameter.
Alternatively, just for this case of pattern accumulator device,
gx_default_get_bits_rectangle() could be used straightly.
Which way (if any) is better?

But the real question is in its caller, gx_default_copy_alpha().
This function must cope with the fact that some bits were not read
from the device, as it happens with the pattern accumulator device.
There, starting from gdevdbit.c:202, how do we blend source pixels
with those of unknown (unread) value?

In this particular case (when unread pixels come from parts of the
uncolored pattern device which do not belong to the pattern) it seems 
to me that we can simply consider unread pixels as 100% transparent.
Question to people who know the rest of the Ghostscript: will it
work in other cases?

Thanks for hints,

Konstantin Shemyak.