Evince doesn't anti-alias graphics

[joehill]

Binary package hint: evince

Scanned documents are very hard to read in evince because, regardless of how high their resolution, scanned images are not (or at least are very badly?) anti-aliased and look jagged unless scaled up to 150% or 200%. By comparison, the same documents look smooth and legible even when viewed at 50% in xpdf or Adobe Reader.

(I'm using Ubuntu 8.04.1, evince 2.22.2-0ubuntu1)

[Pedro Villavicencio (pedro)]

does that happens with all the pdf images you're looking? Can you submit a document example? May you take an screenshot of the issue? thanks,

[joehill (joseph-hill)]

Yes, I have hundreds of black and white documents I've scanned or downloaded and I have the same problem with all of them. Here are two screenshots comparing evince with xpdf and the document they come from.

Although I can basically read it in evince, it hurts my eyes and takes me about twice as long to read as it takes using xpdf. Since I spend a large part of each day reading scanned texts, I've switched to using xpdf to read these documents to save time and my eyes.

[joehill (joseph-hill)]

...another screenshot at somewhat higher magnification. Note the artifacts around some of the letters (such as "2. Humankind") and general jaggedness.

[joehill (joseph-hill)]

...and the pdf file in question (although the same applies to all the b&w scanned pdfs I've tried).

[Pedro Villavicencio (pedro)]

I've tried the document you attached with xpdf, adobe acrobad and evince and it doesn't look quite different to me at least, anyways re assigning to poppler for now

[Pedro Villavicencio (pedro)]

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to New. Thanks again!.

[joehill (joseph-hill)]

I guess we disagree on whether or not the image quality in evince is acceptable. I've been using okular recently because, for me, evince is simply not usable for viewing graphical documents.

[Niall Gallagher (npgall)]

Hi,

I can confirm that this bug is present for me in Evince (Document Viewer) 2.24.1, which is "using poppler 0.8.7 (cairo)". I'm on Ubuntu 8.10.

This bug renders Evince useless for displaying PDFs which contain high resolution graphs; graphs which I have to look at daily. Specifically this is going to affect badly the display of PDF files which contain images having a higher resolution than the screen on which they will be displayed. Such rendering will lose information in the source image entirely. PDFs which contain images having a lower resolution than the screen on which they will be displayed will not be affected so badly; no pixels will be ignored. But such enlarged images will not look smooth.

See attached screenshots of the same page in the same PDF rendered both in Evince and in Adobe Reader 8 (which I've installed as a stop-gap). Both are rendered at 100% zoom. Clearly the Evince-rendered graph is badly broken. Parts of the line graph are not rendered at all.

Knowing a bit about image manipulation; this is because Evince is simply displaying every nth pixel from the high-res source image on screen verbatim (without interpolation), instead of displaying an average of source pixel values around the sample points within the source image. Evince ignores the pixels between sample points in the source image, which in the case of the fine-detailed graph causes it to not render parts of the graph at all.

[Niall Gallagher (npgall)]

Same PDF rendered in Adobe Reader 8.

[Niall Gallagher (npgall)]

Reopening bug. Attached screenshots which confirm the issue.

[Niall Gallagher (npgall)]

Changing bug status from 'confirmed' to 'new' per instructions on how to re-open it. Note that I've attached evidence which confirms the bug.

[odaagan (teitur-arnarson)]

I've had the same problem for as long as I can remember (i.e. since 2006 or so). My solutions so far have been either to convert the document to djvu-format (using any2djvu) or to read it in okular (former kpdf?), which does not have this rendering problem.

In the attachement you see to the left the evince version and to the right the okular version.

[Daniel Pirch (dpirch)]

The bug is still present in Jaunty. Evince is hardly usable for certain documents, you have to use Okular or Adobe Reader
 instead.

[syrex314 (syrex314)]

Same bug persists in Jaunty, evince version 2.26.1. Problem occurs most frequently in scientific literature that I've downloaded. Okular and Acrobat reader render the same PDFs just fine. Contemplating switch to KDE...

Attached screenshot showing okular (left hand side of screen) vs evince (right hand side of screen) rendering of same PDF.

[schmolch (saschaheid)]

Same here.
I can not view b/w scans with poppler, is there no aa switch we can enable?

[Alexander Jones (alex-weej)]

This is embarrassing. It seems anything non-text isn't anti-aliased!

[Peter Ballinger (peter-j-ballinger)]

Actually, it's not -quite- "anything non-text". It's anything in 1bit black and white color, such as most scanned documents. Grayscale or color images are antialiased, but for some reason not the black and white document scans that could benefit the most. They're displayed as eye stabbing crunchy aliased illegibility.

[huug (dsjarw)]

I just upgraded to Karmic hoping for improvement, but it got worse. The AA used to be bad, now there is none. If you look carefully at the okular vs evince image you'll see some grey pixels in the evince rendered text. This is how it used to look on my system also, but now there is only black and white resulting in complete illegibility.
Is someone working on this?

[loafing (guojq28)]

Still happens on Karmic for me. It is even worse than reading it using google doc.

In the attached screen shot, the left side is open in google doc since it is an email attachment.
The right side is open by evince.

If the problem cannot get solved, I cannot read paper on ubuntu. So kind of I got to switch back to windows.

Thanks if somebody will solve this.

[joehill (joseph-hill)]

Hi Loafing,

I'm using okular to read pdfs for the moment, and occasionally xpdf for all the PDFs that crash okular and evince. I haven't seen any developer interest in this bug, so I'm not holding my breath to be able to use evince any time soon.

On the bright side, there are several pdf readers available on Ubuntu, all of which anti-alias well except evince, so there's no need to switch operating systems.

Joe

[Alexander Jones (alex-weej)]

acroread is what most of the academics in my department settle with, for
exactly this reason.

2009/10/31 joehill <email address hidden>

> Hi Loafing,
>
> I'm using okular to read pdfs for the moment, and occasionally xpdf for
> all the PDFs that crash okular and evince. I haven't seen any developer
> interest in this bug, so I'm not holding my breath to be able to use
> evince any time soon.
>
> On the bright side, there are several pdf readers available on Ubuntu,
> all of which anti-alias well except evince, so there's no need to switch
> operating systems.
>
> Joe
>
> --
> Evince doesn't anti-alias graphics
> https://bugs.launchpad.net/bugs/248355
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Max Sadrieh (max.sadrieh)]

I can confirm this bug. It seems to be a problem with poppler as both evince and epdf have this problem. Neither acroread nor xpdf have it.

This bug appeared after I upgraded to Karmic.

Attached is a screenshot of the 4 applications.

[huug (dsjarw)]

I did some research and found out that this is a Poppler bug and is related to this bug :

http://lists.freedesktop.org/archives/poppler-bugs/2007-February/000828.html
also https://bugs.launchpad.net/ubuntu/+source/poppler/+bug/199916

In order to fix the above bug the interpolation default was turned off (interpolate = gFalse in Gfx.cc)

The core problem is that the cairo backend only seems to do either full bilinear interpolation or none (nearest neighbour) while it should ALWAYS filter during minification and either interpolate or edge smooth during magnification. Until this is available they should put the interpolation default back on.

[Pedro Villavicencio (pedro)]

could somebody still having the issue send this upstream to bugs.freedesktop.org ? Thanks in advance.

[huug (dsjarw)]

I submitted a patch to http://bugs.freedesktop.org/show_bug.cgi?id=5589

[Michael Doube (michael-doube)]

Looking forward to this patch making it downstream. I read a lot of scientific literature and at the moment evince's inability to antialias scanned journal articles (how many of the journals distribute their older material) makes me kill trees by printing out articles, just so the text is legible.

[Alexander Jones (alex-weej)]

acroread

2009/11/22 Michael Doube <email address hidden>:
> Looking forward to this patch making it downstream.  I read a lot of
> scientific literature and at the moment evince's inability to antialias
> scanned journal articles (how many of the journals distribute their
> older material) makes me kill trees by printing out articles, just so
> the text is legible.
>
> --
> Evince doesn't anti-alias graphics
> https://bugs.launchpad.net/bugs/248355
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Michael Doube (michael-doube)]

Worse, Acrobat on XP :-P

2009/11/22 Alexander Jones

> acroread
>
>

[molecule-eye (niburu1)]

This bug has been around for ages and it's quite a significant one. At least, it's one that deserves to have been patched years ago!

[Pedro Villavicencio (pedro)]

patches are welcome though.

[Sebastien Bacher (seb128)]

the issue is fixed in git

[Oliver Joos (oliver-joos)]

I checked Lucid alpha 3 booted as Live-CD (evince 2.29.91, poppler 0.12.3) and this bug is not fixed there. Perhaps the fix just did not make it into alpha 3. Otherwise the status of this bug should be reverted.

The attached screenshot shows evince against gscan2pdf in Lucid alpha 3 rendering the same PDF document. The document was scanned and consists of full-page JPGs.

[huug (dsjarw)]

It is fixed in poppler 0.13.1 (unstable) and should go in the stable 0.14 branch when it comes out

[Benjamin Humphrey (humphreybc)]

Our entire team has the same issue in Ubuntu, across Karmic and Lucid. The fonts are okay, but the images are very jagged/not anti-aliased.

I'm not sure whether this is the same issue as what we are having so I have posted some screenshots. If it's the same bug and it has been fixed then that is fantastic, can't wait for it to hit main.

The PDF in question is http://ubuntu-manual.org/ubuntu-manual-draft.pdf

Our team is https://launchpad.net/ubuntu-manual and we're on IRC in #ubuntu-manual on freenode.

[Jeremy Bícha (jbicha)]

Pedro, are you sure this is "fix committed"? Has the new version of poppler (0.13.1 or 0.13.2) been uploaded for Lucid?

[Omer Akram (om26er)]

Jeremy, Fix committed means that bug the bug is fixed upstream but the package has not yet been uploaded for ubuntu but will be.

[Jeremy Bícha (jbicha)]

The distinction between fix committed and fix released isn't clear. I see that the upstream bug was marked fix released which is correct. I thought the Ubuntu-specific bug should be marked fix committed when the fix was uploaded or in -pending, and fix released when it is actually available for people to use. I'm just concerned that this won't be fixed before release unless action is taken...and inaction makes the Ubuntu manual look uglier than it should.

[Anders Kaseorg (andersk)]

The bug task is labelled poppler (Ubuntu), not poppler (Ubuntu Lucid). Since the fix is planned to be uploaded for Lucid+1, this marking is correct.

It would be massively irresponsible to upload a development version of poppler (0.13.x) to Lucid so late in the LTS release cycle. If you want this fixed for Lucid, someone needs to backport the appropriate patches to 0.12.4 and post a debdiff against the current version in Lucid (0.12.4-0ubuntu2). I don’t know how easy that would be, nor whether such a patch would be accepted into Lucid after FeatureFreeze, but at least it would have a chance.

Anyway, my main point is that arguing about the bug status is not going to accomplish anything.

[Sebastien Bacher (seb128)]

the current way settings are used is not optimal right but it's easier to see which bugs have fixes which can be backported or closed in new uploads looking at the lists

the new version will not be uploaded to lucid, it's going to be stable after lucid and depends on an unstable cairo version

[Benjamin Humphrey (humphreybc)]

So we can't get this in Lucid in time?

[Sebastien Bacher (seb128)]

sorry the change there doesn't require cairo change I was thinking about some other one, I reviewed this change some time ago see bug #92296 but the difference was not obvious and none of the example of launchpad seems to render differently, we could get the fix in still if some users can verify it's working as it should

[Josh Holland (jshholland)]

I have fixed this in the branch. Filing a merge request.

[Josh Holland (jshholland)]

I can verify that it fixes the problems too.

[Anders Kaseorg (andersk)]

Josh: Your patch modifies Makefile.am without updating Makefile.in or causing the packaging to run automake. So it fails to build the new object and dies with a linker error.

After fixing that, it seems to work for me on the examples from this bug, such as ubuntu-manual-draft.pdf.

I would suggest annotating the patch to say where it came from:
https://wiki.ubuntu.com/UbuntuDevelopment/PatchTaggingGuidelines

[Launchpad Janitor (janitor)]

This bug was fixed in the package poppler - 0.12.4-0ubuntu3

---------------
poppler (0.12.4-0ubuntu3) lucid; urgency=low

  * Updated the patch to work without having to run autotools at buildtime

  [ Josh Holland ]
  * Add backport-anti-alias.patch: Fix anti aliasing (fixed in upstream git)
    (LP: #248355)
 -- Sebastien Bacher <email address hidden> Wed, 31 Mar 2010 18:10:37 +0200

[sybille (sybillel)]

I checked out the patched version with the Lucid Daily Live CD, and it looks great. Thanks!

Is there any chance that the patch could be backported for Karmic?

[Benjamin Humphrey (humphreybc)]

The patch arrived in Lucid updates today, and while it fixes most of the images, some still remain the same. For example, take the two attachments I posted.

"evince.png" is now fixed, but the second one of Rhythmbox, "evince2.png" remains the same. And they're both in the same PDF.

[Sebastien Bacher (seb128)]

> Is there any chance that the patch could be backported for Karmic?

there is no karmic change schedule for the moment no, lucid be stable in 2 weeks

[sybille (sybillel)]

>there is no karmic change schedule for the moment no, lucid be stable in 2 weeks

Yes, I know that lucid will be released shortly. But I myself will not be upgrading immediately because I am working on a long project and I want to wait until that is finished. The project involves a lot of scanned-paper PDF files, which is why I was asking about a backport. I suppose I will continue to use Okular.

BTW, every PDF I tried is anti-aliased with the patch in lucid. These are all black-and-white images, in varying resolutions (150-600 dpi). The comment above indicating that the patch is not working for all images concerns color images. Maybe that is a meaningful difference.

[Albert Huang (ash-debian)]

Hi,

this doesn't appear to be fixed, at least for the documents I'm looking at.

For example:

http://people.csail.mit.edu/bkph/papers/On_Lightness_OCR.pdf

[joehill (joseph-hill)]

Thanks, I can confirm that this problem is fixed for me in Lucid Beta 1.

[Brewster Malevich (brews)]

I'm with #52, the document ( http://people.csail.mit.edu/bkph/papers/On_Lightness_OCR.pdf ) is nearly unreadable.

[sybille (sybillel)]

For me, some of the pages of document posted in #52 are anti-aliased with the patch in Lucid, and some of the pages in that same document are not.

I haven't found any other PDF file like that in my collection of many hundreds of PDF files (I didn't try all of them, just several arbitrarily chosen groups of different PDF files).

It's odd.

[sybille (sybillel)]

I've attached a screen shot of two pages of the PDF posted in comment #52 as rendered by evince in Lucid (updated on April 11).

Check out the difference in the rendering in the thumbnail images on the left. The thumbnail for page 9, which is anti-aliased, appears in grey tones, while the thumbnails of the pages which are not anti-aliased appear in black-and-white. The pages themselves are rendered similarly to the thumbnails, as the screenshots show.

In xpdf, all of the pages are anti-aliased equally, both in Lucid and in Karmic. Likewise in Okular. Since these two applications also use poppler, it seems that there is something specific to evince that still needs attention.

[sybille (sybillel)]

I changed the status back to "new" to reopen this bug because, as per the last series of messages, the fix to poppler does not fix the rendering in Evince for all PDFs. Sorry if this wasn't the correct action to take; I just wanted to make sure that the bug remains visible.

[Sebastien Bacher (seb128)]

the bug described there has been fixed, if you still have an issue open a new one

[sybille (sybillel)]

>the bug described there has been fixed, if you still have an issue open a new one

Three people in this thread have reported that the bug has not been fixed for all PDFs when viewed in Evince.

[pazuzuthewise (pazuzuthewise)]

I believe I've encountered the same bug in Mint 8 XFCE CE (based on Karmic).
I have evince 2.28.1-0ubuntu1.2 and, respectively, libpoppler-glib4, libpoppler5 and poppler-utils version 0.12.0-0ubuntu2.1
Uploading screenshots of the same scanned (black-and-white) pdf:
- Pdf file: [url=http://www.mediafire.com/?yij2ydy2nzz]http://www.mediafire.com/?yij2ydy2nzz[/url]
- Evince screenshot:
[URL=http://img690.imageshack.us/i/evincescreenshot.png/][IMG]http://img690.imageshack.us/img690/1126/evincescreenshot.th.png[/IMG][/URL]
- Xpdf screenshot:
[URL=http://img641.imageshack.us/i/xpdfscreenshot.png/][IMG]http://img641.imageshack.us/img641/4696/xpdfscreenshot.th.png[/IMG][/URL]

[Giorgi Maghlakelidze (dracid)]

I would like to report the same thing happening on Lucid, Evince 2.30.0
Rendering *VERY* low quality bitmaps.

Fixing this would be a wonderful improvement of Evince experience...
Please look into this. Just take any PDF document with a bitmap inside.

Regards.

[MatthiasA (themaze)]

Fix released? Having the same problem in Ubuntu Lucid x64.
Adobe renders the scans much better than evince.

[m0sia (m0sia)]

The same problem with Lucid up-to-date. Sebastien Bacher, what information do you need to consider that the issue is not fixed yet?

[m0sia (m0sia)]

I've used the patch(#30) and added patched applet to my ppa.

sudo add-apt-repository ppa:m0sia

[m0sia (m0sia)]

sorry, i've missed the window and posted comment to this bug. I don't know how to delete my comment.

[Krzysztof Janowicz (janowicz)]

same problem. pdf's with gradients (e.g. a logo) look good on okular but very bad on evince

[Roman Krylov (volyrkr)]

With poppler-0.14.1 and evince-2.30.3 rebuilt on gentoo looks like fixed too.

[m0sia (m0sia)]

The problem is solved in 10.10.

[vvdghj (vvdghj)]

Evince is not perfect for reading Google (e)books. See attachments in which Evince makes parts of the text completely disappear, wheras Foxit renders them well.
Examples taken from:
http://books.google.com/ebooks?id=tMo6AAAAcAAJ&printsec=frontcover&output=reader

[vvdghj (vvdghj)]

see: https://bugs.launchpad.net/ubuntu/+source/poppler/+bug/450533
 Images not showing in evince, JPX errors