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.?

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".