Created attachment 2761 [details]
poppler wrong rendered line

Well, isn't that odd.  I don't why a solid lie would turn into a gradient line
like that, but will look into it.

The line is probably not a stroked path, but a scaled black pixmap. pdftk didn't
want to uncompress this file, so I'm not sure. But here's the relevant part of
xpdf -cmd output:

TJ [(X) 4.52619 (,) -271.951 (S) 3.05095 (G) 0.149484 (M) 2.47507 (L) -252.219
(a) -1.87468 (n) -0.17399 (d) -252.219 (t) 4.80065 (h) -0.17399 (e) -2.80099 (n)
-241.069 (X) 4.52619 (M) 2.47507 (L) 8.75095 (.) 9.09894]
Tf /R11 8.96638
  font: tag=R11 name='OGAAAA+Fp' 8.96638
Td 130.08 4.32
TJ [(2) -8.56716]
ET
Q
q
cm 718 0 0 -2 374.9 600.9
BI
Q
q
cm 4.16667 0 0 4.16667 0 0
BT
Tf /R11 7.57162
  font: tag=R11 name='OGAAAA+Fp' 7.57162
Tm 1 0 0 1 103.68 136.08
TJ [(1) -7.15724]
Tf /R11 9.96264
  font: tag=R11 name='OGAAAA+Fp' 9.96264
Td 4.08 -3.6
TJ [(A) 7.12011 (c) 10.3798 (t) -11.2598 (u) 0.749872 (a) -5.89017 (l) 1.92026
(l) 1.92026 (y) 122.386 (,) -279.98 (t) -11.2598 (h) 3.84052 (i) 1.92026 (s)

Yes that's it, the

  q
  cm 718 0 0 -2 374.9 600.9
  BI
  Q

part is an inline image (specifcally, an image mask).  Switching to
CAIRO_FILTER_NEAREST in CairoOutputDev::drawImageMask() fixes it, so we should
probably do that (for CairoOutputDev::drawImageMask() too).  Even better, we
should read the /Interpolate image dict entry to enable filtering when the
document requests it.

Are there any plans to address this bug? I know that it
seems like it's not a big deal, but it renders (no pun
intended) evince nearly unusable for people who regularly
read technical documents compiled from LaTeX. I know that
this does not occur for all LaTeX'ed documents, but it does
occur, for instance, with (as far as I can tell) all pdfs
downloaded from the e-print archive at www.arXiv.org. This
means that physicists, biologists, computer scientists, and
anyone else who uses the arXiv can't use evince in their
daily work, because of what appears to be a pretty simple bug.

I wish I could do it myself, but I haven't programmed in
years and have no idea where to begin. I'm not trying to
complain too much, just draw attention to a persistent bug
that was last commented on four months ago.

(In reply to comment #4)
> Yes that's it, the
> 
>   q
>   cm 718 0 0 -2 374.9 600.9
>   BI
>   Q
> 
> part is an inline image (specifcally, an image mask).  Switching to
> CAIRO_FILTER_NEAREST in CairoOutputDev::drawImageMask() fixes it, so we should
> probably do that (for CairoOutputDev::drawImageMask() too).  Even better, we
> should read the /Interpolate image dict entry to enable filtering when the
> document requests it.

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

Created attachment 4061 [details]
Fairly good testcase for this bug

Here's a rather good testcase for the bug with lots of instances of it. Evince
also takes a very long time (minutes) at 100% cpu to render many of the pages,
which seems to indicate that it might be a good performance testcase as well.

In gv, xpdf, and acroread, the document looks fine and displays quickly. In
gpdf, many of the thinner lines are left out, but performance still isn't a
problem.

I would personally appreciate it if this bug was fixed soon, as it basically
makes evince all but unusable for perhaps about half of the documents I tend to
want to view. This problem also tends to occur very frequently in mathematical
formulas rendered by LaTeX, notably in the overbar for square roots and complex
conjugate, and the horizontal line used to denote a fraction. In some cases,
the formulas can become next to impossible to read.

This appears to be identical to an issue librsvg discovered when using cairo to
scale up images with either a width or height of one pixel.

There is likely a cairo bug here, (or it's possible it could be declared a
feature---I haven't looked closely enough) but if poppler would just set
CAIRO_FILTER_NEAREST in the case of images where one of the dimensions is 1 then
that might be good enough for working around the bug (and without making the
scaling of larger images look nasty).

In comment #4, Kristian mentioned the drawImageMask function in which that
workaround could go, (and it looks like he meant to suggest another function,
but instead listed the same one twice). For actually implementing what he said,
the fix should be quite simple, simply conditionally using CAIRO_FILTER_NEAREST
instead of CAIRO_FILTER_BEST in the case where the image width or height is
equal to 1.

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

using CAIRO_FILTER_NEAREST doesn't work because lines will disapear if they are
scaled to dimensions that cairo doesn't like.

Created attachment 4634 [details] [review]
patch that should fix the problem

Works around the cairo problems by drawing rectangles for 1x1 images.

Fixed in cvs

Cairo bug 5904