Evince has very bad quality when printing pdf files.

After discovering that I had the same problem with another printer, I tried with kpdf, and printing is perfect. Evince has very bad quality when printing pdfs.

One hint about the Ricoh problem which you described in your original bug report. Due to space reasons we could not put all manufacturer-supplied PostScript printer PPDs onto the desktop CDs. To get the full set including all Ricoh PPDs, install the openprinting-ppds-extra package. This will naturally not have any influence of the output quality of evince, but it gives you access to the full functionality of your printer.

Thanks a lot. This should be suggested at some stage after installation.

There is no other bug about that, maybe that's a configuration issue

Just today I was talking to a collegue who had the same problem on gutsy beta. He used acroread and he went fine. However, I tried to print via cups-pdf and the produced pdf is just fine. Sebastien, do you have any advice on how to produce more information?

It seems that I spoke too early. I printed again one page via cups-pdf, both from evince and from kpdf. I attach the results of both. The one printed via evince occupies much more disk space, and if you zoom onto that you'll notice these are bitmaps.

Thanks for your bug report. This bug has been reported to the developers of the software. You can track it and make comments here: https://bugs.freedesktop.org/show_bug.cgi?id=12769

Also confirmed here, Gutsy amd64, evince 2.20.1. The bad printing quality can already be seen in the printing preview...

For me, this bug seems to be fixed since the newest updates (till 12-04) for my Gutsy amd64 (evince 2.20.1-0ubuntu1, libcairo2 1.4.10-1ubuntu4.1), printing quality is now normal again.
Can anyone confim this?

The libcairo2 update did not fixed the problem with me, evince's printing quality is still outstandingly bad for some documents

Well, I have certainly noted some improvement. Documents that were completely messed up before now print reasonably and documents, where half of some pages didn't print at all (a different bug) now print correctly. However, not everything is quite all right. I attach a pdf-latex beamer presentation of mine. Everything prints ok, but the nonalphanumeric signs, like < (on slide 6), and different arrows (slide 7 and 9) and stars on slide 11.

The 4th December libcairo2 updates do not fix the issue.

Ah, okay. I agree, that it doesn't fix the bug. I printed two pages on one, which results in good quality. Printing one page still gives bad quality output. Also I notice, that formulas are printed correctly, while normal text is not.

I agree with der_vegi: text is blurry while mathematic formulas are more clear. (see attached screenshot)

Maybe the quality depends on specific fonts.

I have the same problem, too. Try generating a PDF using LyX, for example. I attach a file to illustrate the problem. This PDF file was generated using LyX. Try printing or previewing it: the result is very ugly. Printing the PDF file using Adobe Reader works perfectly.

However, if you generate a .dvi file from the same LyX source, the printing result is perfect.

I also confirm this, with both gutsy and current hardy, although the difference in quality here is much bigger that the PDFs from Vincenzo show. This is mostly with PDFs generated by pdftex using concrete fonts.

Can anyone else confirm that printing two pages on one page results in normal quality? Also I noticed in my attachments above, that the resulting ps for two pages is about a third of the ps for one page...

Printing two pages on one does indeed results in normal quality here.

Printing two pages on one with normal quality here, too.

Maybe it is not a bug of poppler but of cairo? On the freedesktop bug, someone writes "I don't think this is a poppler bug...".

Also, I would propose high priority, because printing .pdf files is a very common task in everyday's use.? Just imagine, how much ink is wasted these days, just because people think, this is a matter of dirty printing heads... ;)

Okay, it is not a problem of cairo. I installed evince, libpoppler1 and libpoppler1-glib from Feisty, which results in good quality output. Sorry for the many posts.

Ops, again I was wrong. "In ev 0.8.x we didn't use cairo for printing." So it could still be an issue of cairo.?

I was hoping that this issue would be fixed now that libcairo2 version 1.5.4 has been uploaded. This is a development version that has two major features:

  - when printing an image, don't change the WHOLE PAGE to an image surface!
  - handle more PS/PDF vector constructions without resorting to an image fallback.

However, this does not seem to be the case. In fact, now both print preview and print-to-ps can take such a long time (with 100% cpu usage) that it seems that evince has crashed/hung - but if you wait long enough it will finish. This seems to be partly because the resulting files are too large. For example, printing a 30-page PDF file that was 271k, results in a 85M postscript file. During the printing to PS, no dialog boxes are shown, and evince seems to be usable as long as you don't go to a new page. Unfortunately, the resulting files look really wierd, in that (sometimes) equations are just missing, as well as text being blurry.

I have attached a very small PDF that illustrates another kind of problem. When printing to PS, you see very blurry image fallbacks for normal text, and very clear equation text (you can zoom in).

So the cairo guys say, it is a problem of poppler, the poppler guys reassign it to cairo.

I'm quite sorry this has not yet been sorted out, I still can't do serious printing with Gutsy computers here at the office, it's a serious stopper.

I can confirm this issue, with evince and my ml-2010.

I'll attach some test images, but my quality issues seem even worse than the ones posted here. The type from my lyx document is almost unreadable. I decided to take a break from trying to read it to post here (I have a headache!).

I don't print very often, so I'm pretty annoyed that now apparently I can't.

Notice for me the grey text is totally invisible in the photo, lighter than the text on the page underneath the one I'm photographing!!

some words (italics) are unreadable because they are so blurry.

Looking close to the output it looks like the text is dithered, no hard edges, no stark black, no edge. The printer is set to 600dpi, so I should be seeing crisp glyphs, not blurry half-tone.

This is on gutsy with the gdi driver for ML-2010.

I agree with gorgor, maybe the importance should be higher than "medium".

The problem is still present in latest Hardy.

Problem is still there and we are about to release LTS, may I ask to developers reading this bug report what is the current situation and if plans are to release hardy with broken default pdf reader - for what a lot of people do with a pdf reader, i.e. print papers.

We could recommend acroread instead, since it actually works. Also, perhaps xpdf works in some cases when evince fails? If so, then we could recommend that.

I don't think getting around the issue is the solution. Evince is the official pdf viewing application for Gnome and should be able to work out of the box.
Also, acroread does not work straightforwardly for amd64. Plus it is a software one has to add manually, just like xpdf.
So fact is Ubuntu would greatly benefit from this issue being fixed before Hardy release, as I see now in the headers of the bug that it was declined for Gutsy and transposed to Hardy.

gorgor: I completely agree.

Why is this considered only "medium"?

Perhaps because evince primarily fails to print SCIENTIFIC pdfs? (I am asking if this is the case)
For example, I think it has a lot of problems with PDFs created by TeX / LyX. But perhaps it works tolerably well with PDFs commonly found on the web? If so, perhaps the bugmasters consider this bug "medium" because they aren't scientists, and it works for them?

Also, maybe this bug will just take a lot of investigation to solve, and that is the reason it is being listed as "medium" instead of "high" priority.

I can confirm this bug as well

There seems to be a fix on its way upstream, see the remote freedesktop-bug.

It's still present in hardy beta.

I didn't have much luck trying the fix for poppler on the freedesktop.org bug.

First of all it's statically linked to evince so you have to recompile evince. You can't just test it by compiling poppler.

Secondly, evince doesn't even compile with any other poppler (0.7.3, 0.8.0) than the distro version.

I must admit that I can't reproduce the bug, but I remember a similar problem I had years ago.
It seems that the printing/display problems have something to do with documents, which were created with some sort of TeX.
You must know that font-handling (embedding) is often a cause for problems. There are T1 (Type 1 = good, don't confuse it with T1 font encoding in your LaTeX source ;-) and T3 fonts. T3 are only the ugly bitmap fonts - I have seen (Alt + Enter in evince; than fonts dialog) that some of the PDFs aren't properly created.

So please check your TeX/LaTeX/LyX-setup (I have installed texlive-fonts-recommended, -extra, -font-utils, and from universe the packages cm-super and lmodern) and your font settings in your sources / LyX-setup.

Now the question is why do acroread, evince, kpdf show different output? Perhaps it is how they handle problems with fonts. I don't know, but it could be a possibility.

Mark: Can you reproduce the problem with the attached PDF?

For me, this 5-page PDF
(i) generates a blurry "Print Preview"
(ii) takes 90 seconds to do so!

Since the "Print Preview" does not match the displayed version of the PDF, this definitely a bug in evince,
not a natural result of using T3 fonts.

(Also, I used to have problems with bitmapped fonts, but I think that was actually a problem in dvips, and the problem was lack of anti-aliasing for on-screen presentations, not for printing; T3 fonts actually printed just fine.)

I can reproduce it on hardy. When you attempt to use PDF printer the same happens - generates a blurry output in ~90 seconds.

@Benjamin Redelings:
I can reproduce it on gutsy.
I have noticed that your PDF includes T1 and T3 fonts. After printing into a new PDF (or preview) the file becomes unusable - all fonts are gone (and the filesize gets 1,2 MiB).

Swistak gave me an idea: I create a "perfect" PDF with pdflatex with embedded T1 fonts. The file is shown in evince in good quality. When I print into a new PDF - the fonts are changed to T1C Cairo-fonts. The original ones are lost. The quality is still okay, but here we definitly see that there are some font handling problems.

What do you think?

I found a fix. Mark was on the right track with the T1 & T3 fonts. I was having the exact same problem, and installing the package cm-super fixed it.

Installing the cm-super package did not fix it for me

wolf87: perhaps you meant that it fixed for you in documents that you compile from latex? In any case, installing cm-super did NOT fix for me this bug, which is very bad quality from evince when printing certain pdf files.

Patch provided here:

http://lists.freedesktop.org/archives/poppler/2008-February/003459.html

works. Please somebody report to upstream (I don't have a bugzilla account there). I succeded in backporting fix to poppler in hardy, but I had a problem: there is an additional argument in more recent versions of poppler:

http://cgit.freedesktop.org/poppler/poppler/tree/glib/poppler-page.cc

static void
_poppler_page_render (PopplerPage *page,
cairo_t *cairo,
GBool printing)

In ubuntu's version, "printing" is lacking. I used "true" instead of "printing" in my version of the patch and it works but developers should really take a look to what's going on.

I attach two updated binary packages, diff will follow.

My patch to current hardy package is here.

I uploaded this fix to the ppa of the ubuntu-quickfix team, which is an open team that, in my mind, should prepare simple fixes to be tested aganst the "current" distribution, that do not seem to harm, while waiting for them to be taken into account by the main distribution developers. Any launchpad user with enough skills to incorporate someone else's patch into an ubuntu package is invited to participate. Clearly, when fixes are incorporated in ubuntu, or if there's a strong enough reason, corresponding packages will be deleted from the ppa.

The sources.list entry is here

https://edge.launchpad.net/~ubuntu-quickfix/+archive

or you can just install individual packages by clicking on debs.

Thanks for the debs Vincenzo, unfortunately they didn't help in my case. In fact the display in evince seems to no longer be anti-aliased, and printing quality was not affected. If I select text in evince, the highlighted text is replaced primarily by squares and other unual character, both with and without your deb files.

I've included the pdf so you can see what I mean and confirm on your system.

I see: the fix I incorporated breaks video antialiasing for certain fonts. It solved things in my test-case but not in the one posted by SqRt7744. On my system, both original poppler and the patched version do not even start printing whereas both kpdf and acroread print correctly Haut_A4.pdf.

I confirm this issue on Hardy. Installing "cm-super" fixed the display issue. After that, the document that Benjamin Redelings added opens instantaneously. However, printing continues to generate a very low quality bitmapped printout.

The problem is there with PDFs created using pdfLatex. I do not have the problem with PDFs generated by ghostscript.

I confirm that the problem is with evince only. No issue with Acrobat Reader.

Vanadium: You misunderstood; The problem wasn't that the document OPENED slowly. The problem was that it took 90 seconds to GENERATE A PRINT PREVIEW.

1. This problem of slowness in Print Preview still exists in current Hardy and current Intrepid.

2. The blurriness of the text is still present, but is less severe.

Edit: Woops. Actually, the blurriness in Print Preview is NOT less severe. It is just as severe as before.

unfortunately we don't have a handle on the fix for this yet, so I'm deferring the bug since we can't really get this done for .1.

I confirm that the bug is still there in intrepid alpha 6.

I also confirm that it is still there (updated Alpha 6, amd64) using:
libcairo2 1.7.6-0ubuntu1
libpoppler3 0.8.7-1
evince 2.24.0-0ubuntu1

Oh, I was wrong: The text in the preview (takes about 1 min to generate) appears blurry only at the beginning. When I zoom in, the quality becomes better after another 2 mins of waiting.
If I print one page into pdf, the generated pdf is 2.4 MB big, the originial with 270 pages is only 4.5 MB. Opening this pdf also takes about 8 minutes, keeping one CPU at 100 %.
Printing the whole document into pdf does not work.

der_vegi: I think you wanted to comment upstream.

I talked with an upstream developer in IRC. The point is that evince uses libcairo and libcairo did not have support for "user fonts". Now that the new feature is implemented in cairo, somebody must actually make poppler _use_ it.

The likely correct upstream bug is

http://bugs.freedesktop.org/show_bug.cgi?id=17497

the bug has been fixed upstream now

On Sun, 2008-11-02 at 11:28 +0000, Sebastien Bacher wrote:
> the bug has been fixed upstream now
>
> ** Changed in: poppler (Ubuntu)
> Status: Triaged => Fix Committed
>

In what upstream version will it appear? Will the fix be backported to
hardy and/or intrepid?

regards
FF

the next upstream version, what number they will use is an upstream question, the backport depends if the changes can be easily applied to the intrepid version and don't create other issues

the bug should be fixed in jaunty, could somebody try and confirm if that's working correctly now?

What packages should I backport to test it in intrepid? Is it unfeasible? I backported popler and evince using prevu but results remain the same, however I suspect that evince is using some .*gnomeprint.* package to print pdfs.

The point is that the backported evince (using prevu) is using libpoppler3 instead of libpoppler4. Is there a quick way to have the backported evince use the backported libpoppler4 or to also build libpoppler3 from the backported poppler from prevu?

You can recompile evince, same version you're using without any
changes to the source. It will be recompiled to use the newest
poppler. I did this to use poppler3 in hardy without any issues.

On Mon, Jan 19, 2009 at 1:21 PM, Vincenzo Ciancia <email address hidden> wrote:
> The point is that the backported evince (using prevu) is using
> libpoppler3 instead of libpoppler4. Is there a quick way to have the
> backported evince use the backported libpoppler4 or to also build
> libpoppler3 from the backported poppler from prevu?
>
> --
> [gutsy] [regression] Evince has very bad quality when printing pdf files.
> https://bugs.launchpad.net/bugs/150187
> You received this bug notification because you are a direct subscriber
> of the bug.
>

dunno how prevu works but rebuilding after installing the new libpoppler should work correctly

I now have all the packages that are generated by the source package poppler, version 0.10.3-0ubuntu1, and recompiled intrepid's evince. I checked using ldd that evince is using the new libraries. However, the problem is still the same. The document called "speciation_state_correlation.pdf", attached to this bug report, when printed to a pdf file via evince, occupies 9.7 megabytes, and has terrible quality. The document indeed contains type 3 fonts. This bug does not seem solved to me.

Maybe evince passes the pdf on to other libraries that maybe use the old libpoppler?

I am now typing from a jaunty alpha 3 live usb pen. I upgraded the system, I correctly got an update of evince and libpoppler. But the bug is still there.

I just booted into the live system of daily-live 20090116.3 (amd64). Still a problem: Printing one page (the same as I tested above) as .pdf produces a 2.1 M file. Looking at it in evince shows blurry equations and text, though after 3-4 min(!) the quality gets better. Does it take so long to render?

Still an issue on a daily-live 20090306, all updates applied.

Vincenzo Ciancia wrote:
> I now have all the packages that are generated by the source package poppler, version 0.10.3-0ubuntu1, and
> recompiled intrepid's evince. I checked using ldd that evince is using the new libraries. However, the problem is still
> the same.

The fix is not in 0.10.x. You need to wait for 0.12 or apply the 13 patches dated 2008-10-31, 2008-11-01, and 2008-11-23 from
http://cgit.freedesktop.org/poppler/poppler/log/?qt=author&q=Adrian

Could someone in ubuntu comment on the patches? These should be applied as soon as possible. Please consider this bug a bit more: I reported it in 2007 and we have a patch here!

Milestoned it, a bug with patches already available should get fixed in Jaunty.

It looks from the patch that it requires cairo 1.8.2, so it would require a non-trivial backport for both hardy and intrepid. Could someone who actually understands it confirm this, and decide if this blocks an eventual SRU?

there is not a patch there is a lot of non trivial patches rather, not really something for jaunty

Thanks for your comment. Is it already taken for granted that the current gnome head will be in jaunty+1? If so we're all set, it is just a matter of waiting. If not it should be milestoned for jaunty+1 then.

This bug is fixed in karmic. Together with the discovery of the impose+ package for scaled booklet printing, I got finally rid of acrobat reader on my computer. Thanks.

the issue is fixed in karmic now

Today I printed the "subgroup(group theory)" page from wikipedia using firefox, to a pdf file, which is small and vectorial. Then re-printed it via evince for reasons that are not relevant, and the obtained pdf is big, bitmapped, and horribly looking.

The re-print from evince is terrible, the one from okular looks good, but the formula on the third page is obscured.

So, my mood is below my shoes for this bug, because it's in the most important program for a scientist: the default pdf viewer. And it makes absolutely necessary to install a proprietary program to do the most basic activity people perceived doable with computers: printing, like with typewriters. It's free knowledge, converted from a free format to another free format, but I need a proprietary program to get a printout.

So please, can somebody help me understand if the cases above are the same bug or not?

Replicated bug on Jaunty without backports. It appears to be an issue with unpatched systems. Testing patched now (will be only system changes).

I have downloaded the PDF and tried evince in Karmic. I printed into a PDF file with the "Print to file" functionality of evince, so it is really evince and not the CUPS filter chain. Pages 1 and 4 get completely bitmapped whereas pages 2 and 3 are treated correctly as text and vector graphics. It seems that page 2 and 3 contain something which makes Poppler bitmap the whole page. Seems that there is some little item inside which Poppler cannot treat as vector graphics and therefore Poppler bitmaps the whole page.

Thanks, do you think this is the same bug that seemed fixed or should I
open a new one? I guess the current bug had to do with fonts but I do
not understand very well all the connections between fonts, images and
so on in pdf.

The low quality printing in your PDF is a different bug. This bug is about Type 3 fonts being printed as a bitmap. The PDF you attached has no Type 3 fonts.

The reason pages 1 and 4 of your PDF are printed as a bitmap are:

- Firefox is using cairo operators that are not natively supported by PDF on page 1 and 4. I don't think there is any reason that Firefox needs to use anything other than CAIRO_OPERATOR_OVER when printing so I consider this a bug in Firefox.

- As a result cairo embeds a fallback image in the PDF for the region drawn with operators not supported by PDF. But the bounding box of the PDF pattern used to draw the fallback image is set to the page size instead of the image size. This is a bug in cairo.

- When poppler is used to print the PDF via the cairo backend the image becomes a full page image due to the pattern bounding box being set to the page size.

I reported a new bug, please triage it and subscribe if appropriate.

https://bugs.edge.launchpad.net/ubuntu/+source/poppler/+bug/394266

is that issue still there using current karmic? evince nows print using pdf dirrectly

Fixed in karmic and thanks all again.

dropping milestone and assignee, it's a low priority target of opportunity if somebody comes with a backported change for hardy

Installing "cm-super" on Hardy fixed it for me. Thanks Mark.

In Oneiric, I still can't print pdfs with Evince that aren't blurred. Works perfectly when printing with acroread.

Bart, probably your problem is not the one reported here, as the reported bug is already fixed.

Please open a new bug with the PDF files attached which come out in bad quality when printed with evince.

Please also follow the instructions on https://wiki.ubuntu.com/DebuggingPrintingProblems, especially the sections "CUPS error_log" and "Capturing print job data". Note that evince re-renders the PDF file when printing it, so that captured print job data is not the same as the original file.

Hardy has seen the end of its life and is no longer receiving any updates. Marking the Hardy task for this ticket as "Won't Fix".