In recent pulls of mupdf, many — perhaps most — horizontal and vertical rules which are rendered black by other pdf interpreters (I’ve tested xpdf, poppler and gs) are instead rendered in various colours. Red and what appears to be a dark yellow seem to be the most common colours. Within a given pdf, one colour seems to get used for all of the rules. I notice this with most of the (recent) pdfs in ArXiV. An example is: http://arxiv.org/pdf/0710.1435v3.pdf LaTeX uses horizontal rules for such things as the division bar in display equations, the rule above the contents of a radical, and stroked boxes. In the above pdf, the rules happen to render in red in my release build. Using a debug build, the colours vary w/in a single document. I presume, since the two builds have different incorrect results, that the bug is an array overrun, or something similar. I’ll followup if I can track it down more narrowly.
In case this is the same issue as mine, the following would be the patch: diff -r 27dbba5ea9e6 draw/imagedraw.c --- a/draw/imagedraw.c Sat May 01 14:31:12 2010 +0200 +++ b/draw/imagedraw.c Wed May 05 20:45:21 2010 +0200 @@ -207,9 +207,10 @@ static void img_4o4(FZ_PSRC, FZ_PDST, FZ static void img_w4i1o4(byte *argb, FZ_PSRC, FZ_PDST, FZ_PCTM) { byte alpha = argb[0]; - byte r = argb[4]; - byte g = argb[5]; - byte b = argb[6]; + /* cf. http://bugs.ghostscript.com/show_bug.cgi?id=691281 */ + byte r = argb[1]; + byte g = argb[2]; + byte b = argb[3]; byte cov; byte ca; while (h--)
The patch in comment 1 fixes this bug. I’ve not seen any signs of negative side effects, but haven’t tested conclusively. The patch does seem self-evident, though.
*** Bug 691276 has been marked as a duplicate of this bug. ***
Patch has been applied, thanks for finding the problem!