Low quality of text rendering in Evince

[Jan Frybort]

Binary package hint: evince

Feisty on amd64. After recent update of poppler, there is a terrible problem with text rendering in some pdf documents. I have problems with this file http://lpsc.in2p3.fr/gpr/MURE/pdf/UserGuide.pdf. Other files I tried are rendered even nicer than before.

[Luogni-tin (luogni-tin)]

I can reproduce this bug with cairo-1.0.2 (dapper packages). I've tried with
current cairo git and now loading the file is fast (less than a second).

[Freedesktop-pragmata (freedesktop-pragmata)]

Thanks for the interesting news. I guess I'll wait for the release of the stable
version.

[Freedesktop-pragmata (freedesktop-pragmata)]

Luca, I have tried it with cairo-1.0.4 and it is as slow as it was with
cairo-1.0.2. Could you confirm this? (Include the date you downloaded cairo git,
if 1.0.4 doesn't fix the bug.)

[Jeff Muizelaar (jeff-infidigm)]

The difference that matters here is probably the version of xserver you are using.

[Freedesktop-pragmata (freedesktop-pragmata)]

I don't think so
(http://mces.blogspot.com/2006/03/new-cairo-stable-release.html#114274706364115581),
Jeff. (Correct me, if I'm wrong.)

Thanks, anyway.

[Freedesktop-pragmata (freedesktop-pragmata)]

Opening speed is now fine with cairo-1.1.2, but bitmaps aren't antialiased and
it doesn't look fine (changing summary).

Would it be possible to have all bitmaps rendered by poppler-cairo antialiased?

[Freedesktop-pragmata (freedesktop-pragmata)]

I'm afraid that poppler 0.5.2 and cairo 1.1.2 are not able to display the bitmap
font.

[Jeff Muizelaar (jeff-infidigm)]

This is really a cairo bug. Cairo doesn't do minification filtering so scaling down images doesn't look very
good. Until cairo gets minification filtering I don't think there is really anything that can be done...

Also, the poppler 0.5.2 problem is now fixed in cvs.

[Jeff Muizelaar (jeff-infidigm)]

Created an attachment (id=8041)
pre-scale images instead of having cairo scale them.

A very rough and only briefly tested patch that should fix this problem.

[Jeff Muizelaar (jeff-infidigm)]

Created an attachment (id=8048)
pre-scale images instead of having cairo scale them ver 2

A slightly better version.

[Jeff Muizelaar (jeff-infidigm)]

*** Bug 9149 has been marked as a duplicate of this bug. ***

[Jeff Muizelaar (jeff-infidigm)]

*** Bug 8982 has been marked as a duplicate of this bug. ***

[Jeff Muizelaar (jeff-infidigm)]

*** Bug 8844 has been marked as a duplicate of this bug. ***

[Jeff Muizelaar (jeff-infidigm)]

*** Bug 4420 has been marked as a duplicate of this bug. ***

[Jan Frybort (jan.frybort)]

Binary package hint: evince

Feisty on amd64. After recent update of poppler, there is a terrible problem with text rendering in some pdf documents. I have problems with this file http://lpsc.in2p3.fr/gpr/MURE/pdf/UserGuide.pdf. Other files I tried are rendered even nicer than before.

[Jan Frybort (jan.frybort)]

I add a screenshot comparing xpdf and evince.

[Sebastien Bacher (seb128)]

Thank you for your bug. I've forwarded it upstream: https://bugs.freedesktop.org/show_bug.cgi?id=10302

[Sebastien Bacher (seb128)]

*** Bug 10302 has been marked as a duplicate of this bug. ***

[Jeff Muizelaar (jeff-infidigm)]

Created an attachment (id=9278)
Latest patch.

Really ugly code but it should work. It should even do a better job than splash.

[cerealkilla (cerealkilla23)]

I'd like to confirm that this bug also occurs on my system, and that it only seems to happen with pdfs that I've converted using ps2pdf.

[bhaagensen (bhaagensen)]

There is a patch floating around at bugs.freedesktop.org.

https://bugs.freedesktop.org/show_bug.cgi?id=5589

I tried it and it seems to work, though I haven't tested extensively. Still I urge you to consider including it in feisty since without it basically documents with bitmapped fonts (such as the above) is basically unreadable.

[Giorgio Vazzana (mywing)]

I can confirm this too, and the problem happens only with pdf files that use Type 3 fonts (you can check which type of fonts your document is using by pressing ALT+Enter in Evince).
Just a piece of advice: if you are using Latex and the Computer Modern fonts to write your documents, make sure you use the Type 1 version of the Computer Modern fonts (also called "bluesky"), so that you won't have any problem with this bug (for example, if you're using tetex like me, just install the package tetex-extra and you're done). I hope this helps.

[Carlos Garcia Campos (carlosgc)]

Any progress on this Jeff? I think this bug is a blocker for poppler 0.6, it would be really nice to have this fixed before, even though it's not fixed in cairo.

[Jeff Muizelaar (jeff-infidigm)]

It would be good to hear how the current patch works for people. I probably wont have any time to look at this before 28th of July or so.

[Freedesktop-pragmata (freedesktop-pragmata)]

Created an attachment (id=10826)
bitmap font text that poppler doesn't scale

Jeff, bitmap font texts are displayed antialiased (or simply better) appliying your patch.

But at least with text, it seems that bitmap text does not scale at all.

The bug is not introduced by your patch, because I had the bug after moving to poppler-0.5.9.

I guess this should be fixed before the final 0.6 release.

[Freedesktop-pragmata (freedesktop-pragmata)]

Created an attachment (id=10827)
bitmap font right scaled by poppler-0.5.4

As announced before, a bug might have been introduced in poppler-0.5.9 that scales bitmap font texts wrong. poppler-0.5.4 scales the image right.

[Carlos Garcia Campos (carlosgc)]

Is this bug related to #11421? with current cvs head this document:

http://dmi.uib.es/~loren/docencia/propostaproj2005.pdf

is rendered fine, but document attached to bug #11421 is still wrong rendered.

[Jeff Muizelaar (jeff-infidigm)]

Yeah, they are related. My guess is that the pdf in 11421 uses drawImage() instead drawImageMask() and so was affected by the fix that I committed.

[ropers (ropers)]

I've previously posted the following info at bug 26118, but was advised that it's probably related to this bug, so I'm reposting things here:

I'm also seeing absolutely atrocious font rendering with some PDF files in evince.

gpdf renders the same PDFs much better, but appears to use different fonts and ignore settings such as "bold".

Please see the following two screenshots for comparison. Yes, this is the same document, in evince and in gpdf on Ubuntu 6.10.

Evince pdf screenshot:
http://librarian.launchpad.net/7035137/Screenshot.evince.png

gPDF pdf screenshot:
http://librarian.launchpad.net/7035138/Screenshot.gpdf.png

And this is the actual PDF file the above screenshots were taken with:
PDF file that is rendered badly in evince (and gPDF is not too great either):
http://librarian.launchpad.net/7035319/18280.pdf

[ropers (ropers)]

To add: I'm just noticing now that after upgrading to Ubuntu 7.04, the issue appears to be resolved for me -- I get decent PDF rendering in evince 0.8.1 now. If others can confirm this, then maybe this bug could be closed?

[Carlos Garcia Campos (carlosgc)]

Jeff, is it possible then to fix bug #11421 by using the same code, or at least the same approach?

btw, there are some documents that are crashing now in this assert() in CairoOutputDev::drawImageMaskPrescaled():

if (n != 0) {
       printf("n = %d (%d %d %d)\n", n, head_pad_size, pix_size, tail_pad_size);
      assert(n == 0);
}

like the one reported here:

http://bugzilla.gnome.org/show_bug.cgi?id=468667

[Jeff Muizelaar (jeff-infidigm)]

(In reply to comment #23)
> Jeff, is it possible then to fix bug #11421 by using the same code, or at least
> the same approach?

Yes it is possible to fix it using the same approach. Though it would take a little bit of work.

>
> btw, there are some documents that are crashing now in this assert() in
> CairoOutputDev::drawImageMaskPrescaled():
>
> if (n != 0) {
> printf("n = %d (%d %d %d)\n", n, head_pad_size, pix_size,
> tail_pad_size);
> assert(n == 0);
> }
>
> like the one reported here:
>
> http://bugzilla.gnome.org/show_bug.cgi?id=468667

I've just fixed this in CVS.

-Jeff

[Joe Harrington (joeharr)]

No, sorry, I'm on Feisty with evince 0.8.1, and I get terrible Type-3 handling. See the attached screen shot. The left is gv (running ghostscript) on the attached Python tutorial. The middle is evince on the same document. The right is evince on my syllabus, which is also attached. The tutorial uses mostly CMR Type 3 fonts, but the syllabus uses Type 1 and TrueType. Acroread does as well as ghostscript.

--jh--

[Joe Harrington (joeharr)]

Ok, that should have said see text below... Here's the Python tutorial.

--jh--

[Joe Harrington (joeharr)]

And for the record, my system is 7.04 i386 32-bit with patches to date. Also, bug #59316 and bug #69731 seem to be the same. Note that they are older, so the libpoppler thing might not be the solution. If these render well for you on 7.04 patched, we should compare installed package lists.

--jh--

[Joe Harrington (joeharr)]

And for the record, my system is 7.04 i386 32-bit with patches to date. Also, bug #59316 and bug #69731 seem to be the same. Note that they are older, so the libpoppler thing might not be the solution. If these render well for you on 7.04 patched, we should compare installed package lists.

To my eye, it is not antialiasing the Type-3 fonts.

--jh--

[Chris Wilson (ickle)]

*** Bug 12270 has been marked as a duplicate of this bug. ***

[Jeff Muizelaar (jeff-infidigm)]

Bug #9860 is related to this bug.

[Jeff Muizelaar (jeff-infidigm)]

*** Bug 11421 has been marked as a duplicate of this bug. ***

[Felipe Figueiredo (philsf)]

Bug #20310 also links to the same upstream bug. Are this and that one dups? (sure seems like).

If someone decides to mark that as a dupe of this one (or the other way around), there might be interesting information there to repost here, for a centralized view of the issue. I'll try to link the screenshots.

Screenshot comparing evince with kpdf
http://launchpadlibrarian.net/1511057/Evince_Kpdf.png

Screenshots from Bug #138651 (dupe from #20310)
http://launchpadlibrarian.net/9205489/evince-175percent.png
http://launchpadlibrarian.net/9205505/kpdf-175percent.png
http://launchpadlibrarian.net/9205536/evince-100percent.png

[Felipe Figueiredo (philsf)]

Links from dup bug #138651

http://www.inference.phy.cam.ac.uk/mackay/network.pdf
http://launchpadlibrarian.net/9205489/evince-175percent.png
http://launchpadlibrarian.net/9205505/kpdf-175percent.png
http://launchpadlibrarian.net/9205536/evince-100percent.png

[schmolch (saschaheid)]

I was unable to apply the patch to poppler-0.10.7, may i ask what the current situation regarding this bug is?

[Brewster Malevich (brews)]

Anyone working on this?

[Sebastien Bacher (seb128)]

> Anyone working on this?

Not in the ubuntu team at least but you can try to ask upstream too

[Bugs-philosof (bugs-philosof)]

Created an attachment (id=31130)
jstor pdf. Drag the background to a new evince and it looks fine.

Using poppler 0.12.0
It is hard to read jstor pdfs because of this bug.
If I open the pdf I see a badly rendered picture.
However, if I drag the background (drag from a blank area) to a new evince window, it will load the background image nicely rendered.
So it is possible to render the image much nicer, it just doesn't.

But maybe the change in image quality is because evince doesn't use poppler for displaying image files, so when I drag the background image to a new evince it doesn't use poppler?

[Carlos Garcia Campos (carlosgc)]

(In reply to comment #29)
> But maybe the change in image quality is because evince doesn't use poppler for
> displaying image files, so when I drag the background image to a new evince it
> doesn't use poppler?
>

No, the background is not a pdf document, but an image which is rendered with GdkPixbuf.

[Bugs-philosof (bugs-philosof)]

(In reply to comment #30)
> (In reply to comment #29)
> > But maybe the change in image quality is because evince doesn't use poppler for
> > displaying image files, so when I drag the background image to a new evince it
> > doesn't use poppler?
> >
>
> No, the background is not a pdf document, but an image which is rendered with
> GdkPixbuf.
>

So my issue is fixed if either cairo is fixed and thus scales the image nicely, or worked around by prescaling the image before handing it to cairo?

Reassigning bug because it seems jeff is not working on this anymore (no reply since feb. 2008 and no reply to comment #28 aug. 2009).

[Carlos Garcia Campos (carlosgc)]

(In reply to comment #31)
> (In reply to comment #30)
> > (In reply to comment #29)
> > > But maybe the change in image quality is because evince doesn't use poppler for
> > > displaying image files, so when I drag the background image to a new evince it
> > > doesn't use poppler?
> > >
> >
> > No, the background is not a pdf document, but an image which is rendered with
> > GdkPixbuf.
> >
>
> So my issue is fixed if either cairo is fixed and thus scales the image nicely,
> or worked around by prescaling the image before handing it to cairo?

I hope it's fixed in cairo/pixman soon.

> Reassigning bug because it seems jeff is not working on this anymore (no reply
> since feb. 2008 and no reply to comment #28 aug. 2009).
>

Well, maybe Jeff is not working on this bug anymore, but he is still working on this issue in pixman/cairo side, see:

http://lists.cairographics.org/archives/cairo/2009-July/017867.html

[huug (dsjarw)]

Created an attachment (id=31242)
prescale patch

Here is my patch that adds prescale capability

[huug (dsjarw)]

Created an attachment (id=31245)
updated patch

[schmolch (saschaheid)]

Thank you very much, your patch seems to work great.

[Chris Wilson (ickle)]

(In reply to comment #34)
> Created an attachment (id=31245) [details]

Some comments first on the presentation of the patch:

 * just send the patch by itself, there's no need to include the modified file as well - the patch is much easier to read.

 * generate the patch using "diff -urNp old new" when doing so manually. However, git will generate easy-to-read patches with either "git diff", or preferably "git format-patch -1". Note the latter will require you to commit your changes and so also will include a changelog entry and a record of authorship. (And means we can very simply apply the patch to our git trees.)

 * Please try to conform to the coding style of the file you are modifying.

My opinion is that this is vital to get this into pixman as soon as possible - however, the core poppler developers want to get a workaround into poppler now. In terms of implementation, I see nothing fundamentally wrong with the patch (it implements a basic 2D box filter, that would be worth a comment or a better function name!) - though the patches proposed for pixman should achieve better performance.

[huug (dsjarw)]

(In reply to comment #36)
Thanks for your comments

-Regarding presentation: you're probably right. I'm pretty much clueless here. Please let someone in the know (yourself?) fix this to get this patch accepted. For someone who has done this already this shouldn't take much time. I would have to install git, read the man pages etc, probably only to realize nobody is interested in this patch.

-I think this or any other fix should be implemented asap since it renders a lot of pdf readers useless when scanned documents must be read.(e.g. all older scientific papers). I had to install acrobat reader on Ubuntu. This is ludicrous.

-As for the pixman implementation. This might be better, but performance wise I wouldn't expect too much from it because this filtering just doesn't take very long compared to all the other processes. If you are interested in speed it might be worthwhile to write a separate one bit drawimage function. The majority of the the scanned documents are one bit (b/w). In the current implementation the one bit stream is converted to a byte stream then to a ARGB image and then prescaled which is a roundabout way of doing this.

[Tammer Ibrahim (tammeri)]

I can confirm the same behaviour. I'm using Document Viewer 2.28.1 with poppler 0.12.0 (cairo). I have ubuntu 9.10 karmic.

I'm not sure if it happens with every PDF, but it definitely happens with the book scans from my library.

[Carlos Garcia Campos (carlosgc)]

*** Bug 25244 has been marked as a duplicate of this bug. ***

[Václav Slavík (vslavik)]

Note that while this patch does wonders for screen output, it horribly degrades printed output in Evince -- it very much looks like the same downscaled image is used for printing as well.

[huug (dsjarw)]

Created an attachment (id=31667)
patch with printer exception

Added printing exception. Now only prescaling when not printing.

[Benjamin Mako Hill (mako)]

My version of patch says the first hunk of the most recent patch is malformed. It looks like you're missing half a line or so including initializing a couple variables. I've uploaded the version of the patch that seems to work on my systems. I haven't looked into this in any real depth. Is this right? Or am I just confused?

[Benjamin Mako Hill (mako)]

Created an attachment (id=31683)
fixed version of huug's latest patch (?)

[Václav Slavík (vslavik)]

(In reply to comment #41)
> Is this right?

Yes. So was his previous patch -- I fixed it by hand and then forgot to upload a fixed version, sorry about that.

[huug (dsjarw)]

(In reply to comment #43)
Weird. My diff output seems to be missing parts! (a bug?)
Does the patch work? I don't have a printer.

[Václav Slavík (vslavik)]

(In reply to comment #44)
> Does the patch work?

Yes, thanks.

[huug (dsjarw)]

I don't think this bug is about scanned docs.
For scanned (bitmapped) related problems see https://bugs.launchpad.net/ubuntu/+source/poppler/+bug/248355
and http://bugs.freedesktop.org/show_bug.cgi?id=5589

[Bugs-philosof (bugs-philosof)]

Created an attachment (id=31924)
fixed version of huug's latest patch with added comment

What still needs to be done to get this workaround patch into poppler?
I added the comment before the function that Chris Wilson suggested.

[Carlos Garcia Campos (carlosgc)]

We are working on merge current pixman patches into poppler, because it seems to be a better implementation and more correct fix rather than workaround. Your work is very appreciated anyway, and I'll use your patch if pixman approach doesn't work.

Thanks.

[Bugs-philosof (bugs-philosof)]

(In reply to comment #47)
> We are working on merge current pixman patches into poppler, because it seems
> to be a better implementation and more correct fix rather than workaround.

Is the target 0.12.3 or 0.14.0?

[Carlos Garcia Campos (carlosgc)]

0.14, the next major release.

[Václav Slavík (vslavik)]

(In reply to comment #49)
> 0.14, the next major release.

Wouldn't it make sense to apply this patch (only) to 0.12 branch, then?

[Carlos Garcia Campos (carlosgc)]

*** Bug 25596 has been marked as a duplicate of this bug. ***

[Giorgio Vazzana (mywing)]

The problem is fixed for me on Ubuntu Hardy 8.04 amd64 (Evince 2.22.2 with poppler 0.6.4 (cairo))

[Frédéric Crozat (fcrozat)]

*** Bug 26026 has been marked as a duplicate of this bug. ***

[Frédéric Crozat (fcrozat)]

when compiling latest version of the patch, I see two warnings :

CairoOutputDev.cc:2021: warning: 'buffer' may be used uninitialized in this function
CairoOutputDev.cc:2022: warning: 'stride' may be used uninitialized in this function

as suggested by Vaclav, I might be worth adding this patch in 0.12 branch. I'll push it in Mandriva cooker package, for more tests for now.

[Bob+freedesktop (bob+freedesktop)]

I just tried this patch against the Karmic poppler 0.12.0 (via apt-get source), and it does not fix the problem.

BTW this patch does not apply cleanly, it claims it is malformed on line 71 (?!?!)

[Bob+freedesktop (bob+freedesktop)]

Also, the original PDF in the URL? field above, which is supposed to show this problem has vanished. Can someone upload a PDF which is supposed to have the problem fixed by this patch?

[Rdieter-math (rdieter-math)]

Here's a rebased patch I used (against 0.12.3),
http://cvs.fedoraproject.org/viewvc/devel/poppler/poppler-0.12.3-fdo%235589.patch

[Bob+freedesktop (bob+freedesktop)]

The fedora patch also does not fix this problem. Could the differences between 0.12.0 and 0.12.3 be significant enough to cause this patch not to work?

[Václav Slavík (vslavik)]

(In reply to comment #57)
> Could the differences between
> 0.12.0 and 0.12.3 be significant enough to cause this patch not to work?

No, it works with 0.12.3. Unfortunately, I can't find any previously problematic document that I would be free to upload. Stupid question, but did you patch the right package, if you did it that way? E.g. on Gentoo, I had to add the patch to "poppler-glib", not "poppler".

[Rdieter-math (rdieter-math)]

Reporter in downstream report,
https://bugzilla.redhat.com/548826

Has screenshots showing improvments with the patch.

(fyi, poppler-glib comes from the same poppler tarball)

[Bob+freedesktop (bob+freedesktop)]

On ubuntu, the 'poppler' source package generates all the poppler libraries, including poppler-glib. I just checked with ldd also, and evince is loading my newly-compiled libraries.

For me this bug crops up with older papers from most journals. Someone above mentioned JSTOR and I do see papers from there having this bug. Of course I'm not free to upload them either... :( For those with access to journals, this is the paper I was looking at: http://rmp.aps.org/abstract/RMP/v34/i4/p694_1

[Mikhail Glushenkov (cabal-install)]

> Can someone upload a PDF which is supposed to have the problem
> fixed by this patch?

Bug 25596 has an attached PDF.

[Carlos Garcia Campos (carlosgc)]

Created an attachment (id=32750)
Patch based on pixman patches

I finally have a patch based on the patches that Jeff proposed for pixman. Could you confirm this patch works for your test cases, please?

[Frédéric Crozat (fcrozat)]

I confirm latest "pixman" patch fixes rendering with file from bug #26026

[huug (dsjarw)]

(In reply to comment #62)
> Created an attachment (id=32750) [details]
> Patch based on pixman patches
>
> I finally have a patch based on the patches that Jeff proposed for pixman.
> Could you confirm this patch works for your test cases, please?
>

I tested a few files and it seems to work fine. However rendering speed is reduced considerably compared to my patched setup. :-(
Did you test printing? I don't have one.

[Carlos Garcia Campos (carlosgc)]

(In reply to comment #64)
> (In reply to comment #62)
> > Created an attachment (id=32750) [details] [details]
> > Patch based on pixman patches
> >
> > I finally have a patch based on the patches that Jeff proposed for pixman.
> > Could you confirm this patch works for your test cases, please?
> >
>
> I tested a few files and it seems to work fine. However rendering speed is
> reduced considerably compared to my patched setup. :-(

Yes, but theoretically it gives better results. There are three algorithms in Jeff's patches: integer-box, box and lanczos. The first one is the fastest but it gives the worst quality, lanczos provides the highest quality but it's slower than the others. Jeff suggested me to use box since it provides quite good quality with a reasonable performance.

> Did you test printing? I don't have one.
>

The problem is only in the image backend, so we don't use it when printing.

[Carlos Garcia Campos (carlosgc)]

I've just applied the patch to git master, so that it'll be included in the next unstable release. If performance becomes a problem, we can consider using integer-box instead of box and even trying to improve the way we use the rescaler from poppler.

[Carlos Garcia Campos (carlosgc)]

*** Bug 16173 has been marked as a duplicate of this bug. ***

[Sebastien Bacher (seb128)]

the bug has been fixed in git now

[Carlos Garcia Campos (carlosgc)]

*** Bug 24701 has been marked as a duplicate of this bug. ***

[joehill (joseph-hill)]

I'm glad to see a fix has been committed, apparently to both the text and graphics rendering problems. Just for the record, I don't know what happens in poppler behind the scenes, but is the same process used to render both Type 3 fonts and graphics? If not, I'm confused why this text rendering bug is the same bug as the one I submitted, 248355, which is about anti-aliasing scanned black-and -white graphics, not fonts. Thanks.

[Sebastien Bacher (seb128)]

does anybody has an example of rendering issue on lucid?

[madbiologist (me-again)]

@Sebastien - The pdf in comment 9 renders well in Lucid 10.04. So does the one in comment 13.

Uname: Linux 2.6.32-10-generic i686
Packages: evince 2.29.5-0ubuntu1
                  libpoppler5 0.12.2-2.1ubuntu3

[Jc (kenny-au-ski)]

Hello everybody,

I posted some time ago a font redering problem with evince/poppler, see https://bugs.launchpad.net/ubuntu/+source/poppler/+bug/419715. It turns out that all the examples in the present post are displayed properly for me, yet the pdf in the bug report mentioned is still hardly readable. It happens very frequently to me, and I need to switch to xpdf, which works fine. For instance, I took a random article today just to check, and the first I tried did not work properly, see http://projecteuclid.org/DPubS/Repository/1.0/Disseminate?view=body&id=pdf_1&handle=euclid.cmp/1158328654.

[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 yet. The attached screenshot shows evince against gscan2pdf rendering the same PDF document. The document was scanned and consists of full-page JPGs.

[Oliver Joos (oliver-joos)]

Sorry! My previous comment is related to bug #248355 which was misleadingly marked as duplicate of this one. The confusion began here at comment #16.

So I will move my previous comment and hope that this comment helps to clarify: this bug is about bad FONT rendering, whereas bug #248355 is about bad GRAPHICS rendering (e.g. scanned documents)

[Dave Gilbert (ubuntu-treblig)]

This one still is very bad on Lucid (from 2nd page onwards)

http://rstl.royalsocietypublishing.org/content/6/69-80/3075.full.pdf

When I reported this (or similar) at gnome.org I was told it was the https://bugs.freedesktop.org/show_bug.cgi?id=5589 bug.

Dave

[Anders Kaseorg (andersk)]

This seems to be fixed by poppler 0.12.4-0ubuntu3 (bug 248355).

[Bob+freedesktop (bob+freedesktop)]

This bug appears to still be present in the xournal and epdfview programs. It has been suggested that it is because they use poppler_page_render_to_pixbuf rather than the Cairo backend (which is where this bug was fixed).

Can a poppler expert comment on this?

See: http://sourceforge.net/mailarchive/message.php?<email address hidden> and follow-up messages for some details.

[Carlos Garcia Campos (carlosgc)]

(In reply to comment #69)
> This bug appears to still be present in the xournal and epdfview programs. It
> has been suggested that it is because they use poppler_page_render_to_pixbuf
> rather than the Cairo backend (which is where this bug was fixed).

Not exactly, because when rendering to a pixbuf cairo backend is used too.

> Can a poppler expert comment on this?

I've just found the problem. It's a bug in the glib frontend. The problem is that image prescaling is disabled when rendering for printing, and printing is initialized to True in CairoOutputDev. We are calling CairoOutputDev::setPrinting() in poppler_page_render but it's missing in poppler_page_render_to_pixbuf(). Now, that glib frontend depends on cairo, I'm going to change render_to_pixbuf to call poppler_page_render directly and the problem will be fixed.

> See:
> http://sourceforge.net/mailarchive/message.php?<email address hidden>
> and follow-up messages for some details.

Please, note that poppler_page_render_to_pixbuf() and the other GDK functions are going to be deprecated in a near future, since we are just rendering to a cairo surface and then converting to a gdk pixbuf.

Thanks for reporting.