strange font behaviour - connected letters

[Felipe Figueiredo]

Binary package hint: evince

Hello,

in a particular PDF I have, the letters seem strangely connected, and some appear as symbols. The same file appears nicely in xpdf and adobe reader.

I'm including a screenshot.

How can I provide better information to get it fixed?

[Felipe Figueiredo (philsf)]

I forgot to mention I'm using Feisty.

Here's the screenshot.

[Felipe Figueiredo (philsf)]

And here's the original file.

evince prints it ok, FWIW (except for bug #120861, but that can be worked around).

[Sebastien Bacher (seb128)]

The bug has been opened on https://bugs.launchpad.net/bugs/128074

"Binary package hint: evince

Hello,

in a particular PDF I have, the letters seem strangely connected, and some appear as symbols. The same file appears nicely in xpdf and adobe reader.

I'm including a screenshot.

How can I provide better information to get it fixed?

http://launchpadlibrarian.net/8561960/evince-feisty.png
evince-feisty.png (124.4 KiB, image/png)

I forgot to mention I'm using Feisty.

Here's the screenshot.

http://launchpadlibrarian.net/8561964/Pybus_et_al_2000_Genetics.pdf
Pybus_et_al_2000_Genetics.pdf (156.0 KiB, application/pdf)

And here's the original file.

evince prints it ok, FWIW (except for bug #120861, but that can be worked around)."

[Jeff Muizelaar (jeff-infidigm)]

looks like a font substitution problem and could probably be fixed with fontconfig reconfiguration

[Sebastien Bacher (seb128)]

what sort of reconfiguration are you speaking about?

[Carlos Garcia Campos (carlosgc)]

It's not cairo backend specific. Looks like fontconfig problem.

[Sebastien Bacher (seb128)]

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=11864

[Jeff Muizelaar (jeff-infidigm)]

This isn't really a font substitution problem. Currently we don't adjust the widths of characters when we substitute fonts. xpdf has a hack that compares the widths of the 'm' characters and adjusts the size to match. That hack was removed from poppler when the fontconfig patch went in.

I'm not sure the best way to fix this yet.

[Felipe Figueiredo (philsf)]

What about re-inserting the hack patch? Is it incompatible with the fontconfig patch?

[Albert Astals Cid (aacid)]

The m-hack has been reintroduced a while ago.

[Felipe Figueiredo (philsf)]

@Albert
I still get this issue in a lot of documents in evince 2.22.2-0ubuntu1 with libpoppler 0.6.4-1ubuntu1 in Ubuntu 8.04. Has the m-hack been introduced before this bug was posted?

[Albert Astals Cid (aacid)]

poppler 0.6.4 is old, bug your distribution to update it.

[Felipe Figueiredo (philsf)]

Sebastien,

upstream says the patch was reintroduced a while ago. I still have this issue in hardy.

[Felipe Figueiredo (philsf)]

Even though it's not critical, I think it's important to fix this for hardy. It's a very bad advertising for an otherwise very good application (evince), and degrades the visibility of Ubuntu in general not to be able to properly handle what is expected to be a simple task, in the view of lay people (and indeed works with other apps).

I decided to try fool evince into using poppler3 from intrepid. Intrepid version compiles fine on Hardy, and I managed to replace them with an ugly hack with symlinks between libpoppler.so.3/libpoppler.so.2 and libpoppler-glib.so.3/libpoppler-glib.so.2. Not surprisingly, it was very unstable, and evince crashed on mouseover actions, so I couldn't select/copy to test for other bugs (bug #33288 for example). But it kind of worked.

I'm attaching a new screenshot of the result. It's still not perfect, the "fi" string still appear as an undefined (to me at least) ascii character (look for the first sentence in the abstract: "We describe a unified ...". Also appear in the last two of the abstract). Even so, readbility has improved vastly in this case. Unfortunately, I can't use this hack for production use, since they cause evince to crash more often than not.

Is there a way to backport the needed patch(es) to -updates, or should I file a bug to hardy-backports so the whole 0.8.x is backported?

[Felipe Figueiredo (philsf)]

Even though it's not critical, I think it's important to fix this for hardy. It's a very bad advertising for an otherwise very good application (evince), and degrades the visibility of Ubuntu in general not to be able to properly handle what is expected to be a simple task, in the view of lay people (and indeed works with other apps).

I decided to try fool evince into using poppler3 from intrepid. Intrepid version compiles fine on Hardy, and I managed to replace them with an ugly hack with symlinks between libpoppler.so.3/libpoppler.so.2 and libpoppler-glib.so.3/libpoppler-glib.so.2. Not surprisingly, it was very unstable, and evince crashed on mouseover actions, so I couldn't select/copy to test for other bugs (bug #33288 for example). But it kind of worked.

I'm attaching a new screenshot of the result. It's still not perfect, the "fi" string still appear as an undefined (to me at least) ascii character (look for the first sentence in the abstract: "We describe a unified ...". Also appear in the last two of the abstract). Even so, readbility has improved vastly in this case. Unfortunately, I can't use this hack for production use, since they cause evince to crash more often than not.

Is there a way to backport the needed patch(es) to -updates, or should I file a bug to hardy-backports so the whole 0.8.x is backported?

[Pedro Villavicencio (pedro)]

it's fixed upstream, but is not in the hardy package though, it's not a high priority bug and this can wait till intrepid.

[Felipe Figueiredo (philsf)]

From the ubuntu bug report:

"I decided to try fool evince into using poppler3 from intrepid. Intrepid version compiles fine on Hardy, and I managed to replace them with an ugly hack with symlinks between libpoppler.so.3/libpoppler.so.2 and libpoppler-glib.so.3/libpoppler-glib.so.2. Not surprisingly, it was very unstable, and evince crashed on mouseover actions, so I couldn't select/copy to test for other bugs (bug #33288 for example). But it kind of worked.

I'm attaching a new screenshot of the result. It's still not perfect, the "fi" string still appear as an undefined (to me at least) ascii character (look for the first sentence in the abstract: "We describe a unified ...". Also appear in the last two of the abstract). Even so, readbility has improved vastly in this case. Unfortunately, I can't use this hack for production use, since they cause evince to crash more often than not."

http://launchpadlibrarian.net/15681507/Screenshot-097561u480.png

[Sebastien Bacher (seb128)]

the new version is in intrepid