The bug has been opened on https://bugs.launchpad.net/bugs/150187 "Evince prints every pdf I send, with very bad quality, and printing is very slow. Kpdf does not suffer of this problem, printing is high quality and fast. Looks like evince is rendering pdf to a very low quality image. I also tried printing some text from gedit, and it is of perfect quality too. ... 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. ... 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. ... http://launchpadlibrarian.net/9860625/evince-print.pdf ... http://launchpadlibrarian.net/9860627/kpdf-print.pdf ..."
In evince we are directly rendering into a ps/pdf cairo surface with poppler_page_render(). I'm not sure whether it's a poppler or cairo issue.
I don't think this is a poppler bug... My guess is that we are hitting the image fallback of the pdf surface. I'd expect that images produced should be higher resolution. i.e. Someone should be calling cairo_surface_set_fallback_resolution. Though, I'm not sure who should be doing this. I'd expect the gtk printing infrastructure to do it, but I could be wrong. It looks like there is also a problem with how image masks are scaled. We do the scaling ourselves in poppler and I believe that will cause unnecessarily low resolution results. Also of note, cairo-git does fine grained fallbacks and so the problem is not as noticeable.
(In reply to comment #2) > I don't think this is a poppler bug... > My guess is that we are hitting the image fallback of the pdf surface. I'd > expect that images produced should be higher resolution. i.e. Someone should be > calling cairo_surface_set_fallback_resolution. The first thing I tried was calling cairo_surface_set_fallback_resolution in evince and calling displaySlice with 300 instead of 72 in poppler-glib, but it didn't help. > Though, I'm not sure who should > be doing this. I'd expect the gtk printing infrastructure to do it, but I could > be wrong. In evince we are only using the gtk+ printing dialog, but not gtkprintoperation, so it should be done in evince. > It looks like there is also a problem with how image masks are scaled. We do > the scaling ourselves in poppler and I believe that will cause unnecessarily > low resolution results. > > Also of note, cairo-git does fine grained fallbacks and so the problem is not > as noticeable. > It seems there are many changes in cairo git that fix things in poppler/evince. Do you know if there are plans to release cairo soon?
(In reply to comment #3) I still have this bug. Are there any plan to fix it in the close future ?
Additionally, why does printing a PDF to a PDF surface invoke a raster-image fallback? I could see why, sometimes, printing a PDF to PS would invoke a raster-image fallback. However, normally, printing to PS should only create an image for the parts of the document that cannot be handled using vector graphics. Can someone clarify what is going on?
If that helps: Printing two pages on one page of paper results in good quality, while printing one page on one page does not. Using evince 2.20.1-0ubuntu1, libcairo2 1.4.10-1ubuntu4.1. See launchpad bug for attachments.
Installing old evince 0.8.1, libpoppler1 and libpoppler1-glib from the Feisty repos, leaving cairo unchanged, results in good quality again. So I don't think it is a cairo problem.
(In reply to comment #7) > Installing old evince 0.8.1, libpoppler1 and libpoppler1-glib from the Feisty > repos, leaving cairo unchanged, results in good quality again. So I don't think > it is a cairo problem. > In ev 0.8.x we didn't use cairo for printing.
Beginning from evince 2.20 I cannot print many PDF files using my HP Color Laserjet 2605 printer. It is indicated here: http://bugzilla.gnome.org/show_bug.cgi?id=486740 It seems that these two bugs are related to each other.
I was hoping that this issue would be fixed now when libcairo2 version 1.5.4 is used. 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 fix the problem. 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 during this time 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 pdflatex 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).
Created attachment 13290 [details] Small math PDF that prints with blurry text When printing this PDF to PS, the equation text seems to remain as vector text, but the main text reverts to a very blurry image fallback.
Reassigning to cairo.
In addition to the general "blurry printing" problem, it has been said that poppler has a problem print with image scaling when printing Type 3 fonts as bitmasks. This specific problem may be a poppler problem, rather than a cairo problem. So, I wanted to point out that there may be 2 problems here, and that the example PDF that I posted probably demonstrates the poppler problem, not the cairo problem.
(In reply to comment #12) > Reassigning to cairo. > From the cairo list: "In the one_page.ps attached to the launchpad bug the Type 3 font is blurry while the Type 1 font is very sharp. So the use of fallpage image fallbacks by cairo is not the problem. The cause of the blurry text is most likely the image mask scaling done by poppler on Type 3 fonts."
That's still an issue
Still present with evince 2.21.91-0ubuntu1, libpoppler2 0.6.4-1 and libcairo2 1.5.8-0ubuntu1. So do we know by now, if it is a problem of poppler (which the cairo-devs think) or a problem of cairo? Does the fact, that printing two pages on one results in good quality, give any clue?
(In reply to comment #16) > Still present with evince 2.21.91-0ubuntu1, libpoppler2 0.6.4-1 and libcairo2 > 1.5.8-0ubuntu1. > So do we know by now, if it is a problem of poppler (which the cairo-devs > think) or a problem of cairo? Does the fact, that printing two pages on one > results in good quality, give any clue? Re-assigning to poppler. This appears to be an image scaling problem in poppler. There was a patch committed to poppler which may fix the problem: http://lists.freedesktop.org/archives/poppler/2008-February/003459.html Currently waiting for confirmation that it fixes the problem: http://lists.freedesktop.org/archives/poppler/2008-February/003466.html I suggest testing with poppler 0.7.1 which contains this patch.
Well, I compiled poppler 0.7.3 (with cairo & glib) and still had the problem in evince, which told me it was using poppler 0.7.3 (cairo). But I should add, that I did a quick and dirty installation of poppler, which resulted in evince crashing on some documents... So I would not say that this test was too significant.
Poppler 0.7.1 contains this patch but does not solve the problem. Also confirmed evince was using 0.7.1 with About Dialog.
What version of cairo do you have installed? I have now cairo 1.5.20, poppler 0.6.3, and evince 2.22.0. I cannot reproduce the bug anymore.
I can reproduce with: libcairo2 1.6.0-0ubuntu1 (cairo 1.6.0) libpoppler2 0.6.4-1 (poppler 0.6.4) evince 2.22.1.1-0ubuntu1 (evince 2.22.1) It happens in the Print Preview even. The text is blurry but the equation looks sharp.
Under Fedora 9 (x86_64), this kind of works for me: The print preview of only one page takes about 60 s, but the quality is okay. If I print this one page into a pdf file, the result is 2.4 MB big, while the original document (270 pages) is 4.5 MB. To open this one pdf-printed file, it takes about 3 mins on my machine. Using: Cairo 1.6.4 1.fc9 Poppler 0.8.1 2.fc9 Evince 2.22.2 1.fc9 But regarding the speed and the size of the file and the speed, I still would not consider this as solved.
Fix in git.
(In reply to comment #23) > Fix in git. > how can one pinpoint the patch that fixes this? Could you perhaps attacht it to this bug. Maybe at least the revision in which it appeared in git? Thanks in advance. FF
(In reply to comment #24) > how can one pinpoint the patch that fixes this? Could you perhaps attacht it to > this bug. Maybe at least the revision in which it appeared in git? The 12 commits on master from 0b5ee897 to 0741a4026. They were also posted to the mailing list. See the archives for the end of Oct/beginning of Nov. You will also need cairo 1.8.2.
Using cairo 1.8.6 and poppler 0.10.4 this is still a problem: A pdf-print of one page from a 250 page pdf document with 4.5 MB generates a 2.1 MB file that takes about 2-3 minutes opening until it appears in a good quality. Can anyone confirm this?
(In reply to comment #26) > Using cairo 1.8.6 and poppler 0.10.4 this is still a problem: A pdf-print of > one page from a 250 page pdf document with 4.5 MB generates a 2.1 MB file that > takes about 2-3 minutes opening until it appears in a good quality. Can anyone > confirm this? The fix is not in a released version. You will have to wait for 0.12 or build from git master.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.