Created attachment 5215 [details]
demonstration of the problem

This file demonstrates the problem -- there are 256 black angled lines so the
background gets decremented by 1 for each line and there ends up being an
unwanted gradient.

We shouldn't ever be calling fz_mul255 with negative numbers, if we do it's an oversight in our 
subtraction where those numbers should be "overflown" to 0..255 range.

See {path,text}_w4i1o4() for places where fz_mul255() is called with negative
numbers. For example when painting a black line over a white page (causing the
artifacts in the test file).

Note that overflowing the negative numbers to 0..255 range is completely the
wrong thing to do here, and in fact those callsites do 
fz_mul255((short)r - dst[1], ca)
casting the unsigned chars to signed just to avoid this problem...

See my second suggested patch at the sumatrapdf bug in the URL field for one
possible solution: making fz_mul255 return a properly-rounded positive answer,
and modifying the callsites to only use fz_mul255 with positive values. This
seems solves the immediate problem (although I havent checked the performance
impact).

If you want something more performant, perhaps look at the freedesktop.org
pixman library, where they do something similar, but with optimizations, such as
packing all 4 colour components into an int, thus allowing the equivalent of
fz_mul255 on a full RGBA value in one go (pixman-combine.h). They also have MMX,
SSE, etc accelerated implementations of all the pdf blend modes, in case that is
needed.

*** Bug 690751 has been marked as a duplicate of this bug. ***

This issue has not been fixed yet (in the public repository). Attachment 5215 [details] 
still misrenders while it renders correctly with the proposed fix from 
http://code.google.com/p/sumatrapdf/issues/detail?id=568#c1 .

My bad, looks like I somehow failed to recompile from scratch, even though I 
explicitly made sure I did when testing this fix.