Evince has very bad quality when printing pdf files.

Bug #150187 reported by Vincenzo Ciancia
96
This bug affects 6 people
Affects Status Importance Assigned to Milestone
Poppler
Fix Released
Medium
cupsys (Ubuntu)
Invalid
Undecided
Unassigned
Declined for Gutsy by Sebastien Bacher
Declined for Intrepid by Sebastien Bacher
Declined for Jaunty by Sebastien Bacher
Hardy
Invalid
Undecided
Unassigned
poppler (Ubuntu)
Fix Released
Medium
Sebastien Bacher
Declined for Gutsy by Sebastien Bacher
Declined for Intrepid by Sebastien Bacher
Declined for Jaunty by Sebastien Bacher
Hardy
Won't Fix
Low
Unassigned

Bug Description

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.

Revision history for this message
Vincenzo Ciancia (vincenzo-ml) wrote :

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.

Changed in cupsys:
status: New → Invalid
description: updated
Revision history for this message
Till Kamppeter (till-kamppeter) wrote : Re: [gutsy] [regression] Evince has very bad quality when printing pdf files.

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.

Revision history for this message
Vincenzo Ciancia (vincenzo-ml) wrote :

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

Revision history for this message
Sebastien Bacher (seb128) wrote :

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

Revision history for this message
Vincenzo Ciancia (vincenzo-ml) wrote :

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?

Revision history for this message
Vincenzo Ciancia (vincenzo-ml) wrote :

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.

Revision history for this message
Vincenzo Ciancia (vincenzo-ml) wrote :
Revision history for this message
Vincenzo Ciancia (vincenzo-ml) wrote :
Revision history for this message
In , Sebastien Bacher (seb128) wrote :

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

Revision history for this message
In , Carlos Garcia Campos (carlosgc) wrote :

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.

Revision history for this message
Sebastien Bacher (seb128) wrote : Re: [gutsy] [regression] Evince has very bad quality when printing pdf files.

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

Changed in evince:
importance: Undecided → Medium
status: New → Triaged
Changed in poppler:
status: Unknown → Confirmed
Revision history for this message
In , Jeff Muizelaar (jeff-infidigm) wrote :

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.

Revision history for this message
In , Carlos Garcia Campos (carlosgc) wrote :

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

Revision history for this message
In , Léo Studer (leo-studer) wrote :

(In reply to comment #3)

I still have this bug. Are there any plan to fix it in the close future ?

Revision history for this message
In , Benjamin Redelings (benjamin-redelings) wrote :

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?

Revision history for this message
der_vegi (m-may) wrote : Re: [gutsy] [regression] Evince has very bad quality when printing pdf files.

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

Revision history for this message
der_vegi (m-may) wrote :

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?

Revision history for this message
Léo Studer (leo-studer) wrote :

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

Revision history for this message
David Vonka (vonkad) wrote :

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.

Revision history for this message
David Vonka (vonkad) wrote :
Revision history for this message
Andrey Vihrov (andrey.vihrov) wrote :

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

Revision history for this message
In , der_vegi (m-may) wrote :

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.

Revision history for this message
der_vegi (m-may) wrote : Re: [gutsy] [regression] Evince has very bad quality when printing pdf files.

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.

Revision history for this message
der_vegi (m-may) wrote :
Revision history for this message
Léo Studer (leo-studer) wrote :

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

Revision history for this message
Andrey Vihrov (andrey.vihrov) wrote :

Maybe the quality depends on specific fonts.

Revision history for this message
Ricardo Pérez López (ricardo) wrote :

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.

Revision history for this message
Václav Šmilauer (eudoxos) wrote :

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.

Revision history for this message
der_vegi (m-may) wrote :

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

Revision history for this message
Léo Studer (leo-studer) wrote :

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

Revision history for this message
Ricardo Pérez López (ricardo) wrote :

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

Revision history for this message
In , der_vegi (m-may) wrote :

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.

Revision history for this message
In , Carlos Garcia Campos (carlosgc) wrote :

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

Revision history for this message
der_vegi (m-may) wrote : Re: [gutsy] [regression] Evince has very bad quality when printing pdf files.

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... ;)

Revision history for this message
der_vegi (m-may) wrote :

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.

Revision history for this message
In , Serge Gavrilov (serge-pdmi) wrote :

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.

Revision history for this message
der_vegi (m-may) wrote : Re: [gutsy] [regression] Evince has very bad quality when printing pdf files.

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

Revision history for this message
In , Benjamin Redelings (benjamin-redelings) wrote :

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

Revision history for this message
In , Benjamin Redelings (benjamin-redelings) wrote :

Created an attachment (id=13290)
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.

Revision history for this message
In , Carlos Garcia Campos (carlosgc) wrote :

Reassigning to cairo.

Changed in poppler:
milestone: none → ubuntu-8.04
Steve Langasek (vorlon)
Changed in poppler:
milestone: ubuntu-8.04 → ubuntu-8.04.1
Changed in poppler:
assignee: nobody → seb128
Steve Langasek (vorlon)
Changed in poppler:
assignee: nobody → seb128
importance: Undecided → Medium
milestone: none → ubuntu-8.04.1
status: New → Triaged
Steve Langasek (vorlon)
Changed in poppler:
milestone: ubuntu-8.04.1 → none
Steve Langasek (vorlon)
Changed in cupsys:
status: New → Invalid
Steve Langasek (vorlon)
Changed in poppler:
milestone: ubuntu-8.04.1 → ubuntu-8.04.2
Changed in poppler:
status: Confirmed → Fix Released
49 comments hidden view all 129 comments
Revision history for this message
Sebastien Bacher (seb128) wrote : Re: [gutsy] [regression] Evince has very bad quality when printing pdf files.

the bug has been fixed upstream now

Changed in poppler:
status: Triaged → Fix Committed
Revision history for this message
Felipe Figueiredo (philsf) wrote : Re: [Bug 150187] Re: [gutsy] [regression] Evince has very bad quality when printing pdf files.

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

Revision history for this message
Sebastien Bacher (seb128) wrote : Re: [gutsy] [regression] Evince has very bad quality when printing pdf files.

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

Revision history for this message
In , Felipe Figueiredo (philsf) wrote :

(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

Revision history for this message
In , Adrian Johnson (ajohnson-redneon) wrote :

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

Revision history for this message
Sebastien Bacher (seb128) wrote : Re: [gutsy] [regression] Evince has very bad quality when printing pdf files.

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

Changed in poppler:
status: Fix Committed → Fix Released
Revision history for this message
Vincenzo Ciancia (vincenzo-ml) wrote :

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.

Revision history for this message
Vincenzo Ciancia (vincenzo-ml) 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?

Revision history for this message
Felipe Figueiredo (philsf) wrote : Re: [Bug 150187] Re: [gutsy] [regression] Evince has very bad quality when printing pdf files.

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

Revision history for this message
Sebastien Bacher (seb128) wrote : Re: [gutsy] [regression] Evince has very bad quality when printing pdf files.

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

Revision history for this message
Vincenzo Ciancia (vincenzo-ml) 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 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?

Revision history for this message
Vincenzo Ciancia (vincenzo-ml) wrote :

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.

Revision history for this message
der_vegi (m-may) wrote :

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?

Steve Langasek (vorlon)
Changed in poppler:
milestone: ubuntu-8.04.2 → ubuntu-8.04.3
der_vegi (m-may)
Changed in poppler:
status: Fix Released → Confirmed
Revision history for this message
In , der_vegi (m-may) wrote :

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?

Revision history for this message
der_vegi (m-may) wrote : Re: [gutsy] [regression] Evince has very bad quality when printing pdf files.

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

Revision history for this message
In , Adrian Johnson (ajohnson-redneon) wrote :

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

Revision history for this message
Adrian Johnson (ajohnson-redneon) wrote : Re: [gutsy] [regression] Evince has very bad quality when printing pdf files.

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

Revision history for this message
Vincenzo Ciancia (vincenzo-ml) wrote :

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!

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

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

Changed in poppler (Ubuntu):
milestone: none → ubuntu-9.04
Revision history for this message
Felipe Figueiredo (philsf) wrote :

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?

Revision history for this message
Sebastien Bacher (seb128) wrote :

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

Revision history for this message
Vincenzo Ciancia (vincenzo-ml) wrote :

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.

Revision history for this message
Vincenzo Ciancia (vincenzo-ml) wrote :

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.

Revision history for this message
Sebastien Bacher (seb128) wrote :

the issue is fixed in karmic now

Changed in poppler (Ubuntu):
milestone: ubuntu-9.04 → none
status: Confirmed → Fix Released
Revision history for this message
Vincenzo Ciancia (vincenzo-ml) wrote :

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.

Changed in poppler (Ubuntu):
status: Fix Released → Incomplete
Revision history for this message
Vincenzo Ciancia (vincenzo-ml) wrote :
Revision history for this message
Vincenzo Ciancia (vincenzo-ml) wrote :

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

Revision history for this message
Vincenzo Ciancia (vincenzo-ml) wrote :

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?

Revision history for this message
wolf87 (ablocker) wrote :

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

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

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.

Revision history for this message
Vincenzo Ciancia (vincenzo-ml) wrote : Re: [Bug 150187] Re: Evince has very bad quality when printing pdf files.

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.

Revision history for this message
Adrian Johnson (ajohnson-redneon) wrote :

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.

Revision history for this message
Vincenzo Ciancia (vincenzo-ml) wrote :

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

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

Revision history for this message
Sebastien Bacher (seb128) wrote :

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

Revision history for this message
Vincenzo Ciancia (vincenzo-ml) wrote :

Fixed in karmic and thanks all again.

Changed in poppler (Ubuntu):
status: Incomplete → Fix Released
Revision history for this message
Sebastien Bacher (seb128) wrote :

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

Changed in poppler (Ubuntu Hardy):
assignee: Sebastien Bacher (seb128) → nobody
importance: Medium → Low
milestone: ubuntu-8.04.3 → none
Revision history for this message
SanDiego (ergut) wrote :

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

Changed in poppler:
importance: Unknown → Medium
Changed in poppler:
importance: Medium → Unknown
Changed in poppler:
importance: Unknown → Medium
Revision history for this message
Bart Verwilst (verwilst) wrote :

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

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

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.

Revision history for this message
Rolf Leggewie (r0lf) wrote :

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

Changed in poppler (Ubuntu Hardy):
status: Triaged → Won't Fix
Displaying first 40 and last 40 comments. View all 129 comments or add a comment.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.