http://csseminar.kadm.usu.ru/tarragona_volkov2008.pdf is mis-rendered with mupdf's GIT HEAD (and ghostscript 8.71/9.0 too) however version of MuPDF from SumatraPDF's repository is OK.
Created attachment 6738 [details] Sample file. This is a local copy of the sample file. The file is drawn as a sequence of black and white images drawn on the black background. Sometimes, there's a one-pixel positioning difference between the image and the background that results in a black line across the page. On Ghostscript, the problem disappears at the resolution that is a multiple of 200 dpi.
Taking this, as it's to do with scaling.
This problem is to do with images having antialiased edges, even after gridfitting. The weights at the edges of images are slightly less than full, and this is most easily rectified by wrapping the weights slightly. Done in my local repo. Will close bug when the commit makes it to the trunk.
FYI: http://git.ghostscript.com/?p=mupdf.git;a=commitdiff;h=d451b09f75625a1b902c14afdede5242ad66713a significantly regresses the rendering of Type 3 fonts for which the glyphs are stored as images (see e.g. the document attached to http://code.google.com/p/sumatrapdf/issues/detail?id=1046 ).
Fixed in commit: commit b076818f88a3ab152897cd2e65c95cef9afb471f Author: Robin Watts <Robin.Watts@artifex.com> Date: Tue Aug 2 14:06:18 2011 +0100 Another attempt to fix bug 691629. To solve bug 691629 we need to ensure that the scaling weights for every pixel in a gridfitted image sum to 256. I had attempted to do that by enabling the 'WRAP' code, but this has the effect of adding too much bias to the outlying source pixels, resulting in thickened serifs etc. A better fix is to extend the code that is already present to check the weights for validity. If an image pixel is completely covered, then force the weights to 256 by adjusting the largest weight. This still skews the output slightly but it's a much less visible result.