Created attachment 11423 [details] ProblemFile The attached file has a crazy path that is used in filling the image. The path has a number of moves and lineto commands that seem to be the source of the issue. AR and GS render it fine.
The file contains a clippath that is filled by an image. The clippath is a series of rectangles of the form: x0 y0 m x1 y0 l x1 y1 l x0 y1 l x0 y0 l (Repeated for many different values of x0, x1, y0, y1). For most of these repeats y0 == y1, so the rectangles described are 0 height. For just a few, y0 and y1 differ by a small amount. Broadly the rectangles stack up on top of one another, I suspect at 1 rectangle per line of source data of the image. A "feature" of Acrobats rendering is that such clip rectangles which are "1-dimensionally null" are treated as if they are a pixel wide. So the net effect of this rendering in acrobat is that the path is a series of horizontally adjacent 1 pixel rectangles. i.e. a 'solid' area that the image can show through. If you zoom Acrobat to be large enough, the problem becomes apparent even there. When Ghostscript renders these rectangles, the occasional one that is non-zero is expanded according to the fill adjust rules to cover a whole pixel line. Thus gs appears to display the image correctly at screen resolutions. At higher resolutions (e.g. 2000 dpi), the problem becomes apparent there. MuPDF does not attempt to emulate Acrobats clip rectangle rendering 'bug'. Neither does it apply fill adjust rules (because of the use of antialiasing). As such the image appears broken in MuPDF. The simple fact is that MuPDF is producing an accurate depiction of the PDF file.
Protentially test files with similar problems: Bug 690928 - zero-width clip paths rendered differently from gs Bug 691667 - zero-width fills not displayed in case anybody wants to think different.