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]
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:
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