evince doesn't display the correct font

Bug #132417 reported by Simon IJskes on 2007-08-14
26
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Poppler
Unknown
Medium
fontconfig (Ubuntu)
Undecided
Unassigned
poppler (Ubuntu)
Low
Unassigned

Bug Description

Binary package hint: evince

When displaying a PDF document with a non-embedded font 'ArialMT', no attempt is made to display the ArialMT font.

Expected behavior:
evince asking fontconfig to produce the closest match to the ArialMT font.

Actual behavior:
no request for font is seen in debug output of fontconfig.

It might be a poppler issue, poppler seems to convert ArialMT into Helvetica wich receives a less fitting match from fontconfig when Arial is present.

Sebastien Bacher (seb128) wrote :

Could you attach an example to the bug?

Simon IJskes (sim-nyx) wrote :

After trying to find an excellent example, i'll have to amend my bugreport a tiny bit. It is not about ArialMT but about non-embedded: PalatinoLinotype-Roman

It's about document http://www.vmware.com/pdf/vi3_301_201_admin_guide.pdf

The 'normal' text on for instance book page 7, is in acrobat reader a serif typeface, in evince it is a 'sans-serif'.

When i turn on FC_DEBUG=4 and 'printCommands yes' i learn the following:

Add Subst match
        pattern any family Equal "Palatino-Roman"
edit
        Edit family Append "URWPalladioL-Roma";

(indeed: fc-match Palatino-Roman gives: URWPalladioL-Roma.pfb: "URW Palladio L" "Roman", which is in gfonts-x11)

I am not a master in interpreting fontconfig / poppler debug output, but i will try to find the relevant spot:

If poppler encounters the lines:

Tf /TT8 1
  font: tag=TT8 name='PalatinoLinotype-Roman' 1
Tm 10.98 0 0 10.98 153 640.02
Tc 0.0008
Tw -0.0049
Tj (Customizing Guest Op)

It starts finding a proper font match.

FcConfigSubstitute Pattern has 6 elts (size 16)
        family: "Palatino Linotype"(s)
        slant: 0(i)(s)
        weight: 80(i)(s)
        width: 100(i)(s)
        spacing: 0(i)(s)
        lang: "xx"(s)
...
(it passes the opportunity to match a close relative:)
FcConfigSubstitute test pattern any family Equal "Palatino-Roman"
No match
...
(and concludes with:)
Substitute match
        pattern all family NotEqual "sans-serif"
        pattern all family NotEqual "serif"
        pattern all family NotEqual "monospace"
edit
        Edit family AppendLast "sans-serif";

Does this help you any further?

Gr. Sim

Simon IJskes (sim-nyx) wrote :

By the way, i've recompiled libpoppler-glib and removed the internal font face translation (effectively delegating it to fontconfig). And the PDF's look almost perfect.

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

"...
When displaying a PDF document with a non-embedded font 'ArialMT', no attempt is made to display the ArialMT font.

Expected behavior:
evince asking fontconfig to produce the closest match to the ArialMT font.

Actual behavior:
no request for font is seen in debug output of fontconfig.

It might be a poppler issue, poppler seems to convert ArialMT into Helvetica wich receives a less fitting match from fontconfig when Arial is present.
...

After trying to find an excellent example, i'll have to amend my bugreport a tiny bit. It is not about ArialMT but about non-embedded: PalatinoLinotype-Roman

It's about document http://www.vmware.com/pdf/vi3_301_201_admin_guide.pdf

The 'normal' text on for instance book page 7, is in acrobat reader a serif typeface, in evince it is a 'sans-serif'.

When i turn on FC_DEBUG=4 and 'printCommands yes' i learn the following:

Add Subst match
        pattern any family Equal "Palatino-Roman"
edit
        Edit family Append "URWPalladioL-Roma";

(indeed: fc-match Palatino-Roman gives: URWPalladioL-Roma.pfb: "URW Palladio L" "Roman", which is in gfonts-x11)

I am not a master in interpreting fontconfig / poppler debug output, but i will try to find the relevant spot:

If poppler encounters the lines:

Tf /TT8 1
  font: tag=TT8 name='PalatinoLinotype-Roman' 1
Tm 10.98 0 0 10.98 153 640.02
Tc 0.0008
Tw -0.0049
Tj (Customizing Guest Op)

It starts finding a proper font match.

FcConfigSubstitute Pattern has 6 elts (size 16)
        family: "Palatino Linotype"(s)
        slant: 0(i)(s)
        weight: 80(i)(s)
        width: 100(i)(s)
        spacing: 0(i)(s)
        lang: "xx"(s)
...
(it passes the opportunity to match a close relative:)
FcConfigSubstitute test pattern any family Equal "Palatino-Roman"
No match
...
(and concludes with:)
Substitute match
        pattern all family NotEqual "sans-serif"
        pattern all family NotEqual "serif"
        pattern all family NotEqual "monospace"
edit
        Edit family AppendLast "sans-serif";

Does this help you any further?

Gr. Sim
...
By the way, i've recompiled libpoppler-glib and removed the internal font face translation (effectively delegating it to fontconfig). And the PDF's look almost perfect."

i wonder how are we supposed to transform PalatinoLinotype-Roman into Palatino-Roman.

why don't you let fontconfig do the job there?

So you are telling me that
fc-match PalatinoLinotype-Roman
works for you?

The submitter comment suggest it makes the document being rendered correctly

then tell the submitter to come here and speak with me :-)

Sebastien Bacher (seb128) wrote :

I've sent the bug to poppler upstreams on https://bugs.freedesktop.org/show_bug.cgi?id=12839

Changed in evince:
importance: Undecided → Low
status: New → Triaged
yhonewski (yhonewski) wrote :

I´d reported problem in this bug thread, my main concern, the viewer can show chinese only anormally, also a few western document without correct font displayed. For the Chinese case, please see the attached file. The characters seem very strange and hardly readible and it happens everytime I am to view a portable document in Chinese.

Sebastien Bacher (seb128) wrote :

could you subscribe to the bugzilla bug? upstream has some questions on the issue

Changed in poppler:
status: Unknown → Confirmed
Sebastien Bacher (seb128) wrote :

Could you reply to the bugzilla comments?

Changed in poppler:
status: Triaged → Incomplete
Pedro Villavicencio (pedro) wrote :

ping? Can you reply? otherwise we're going to close the bug. thanks

Pedro Villavicencio wrote:
> ping? Can you reply? otherwise we're going to close the bug. thanks

Close the bug, please.

Gr. Sim

is this still valid? and is it really cairo-backend only? I see the same font with current poppler than acroread.

Sebastien Bacher (seb128) wrote :

upstream question

"is this still valid? and is it really cairo-backend only? I see the same font
with current poppler than acroread. "

Maxim Levitsky (maximlevitsky) wrote :

Very valid unfortunately.

Here is a example file that has almost nothing displayed, despite hebrew support installed.

Changed in poppler (Ubuntu):
status: Incomplete → Confirmed
Changed in poppler (Ubuntu):
status: Confirmed → Triaged

I have a problem with some minor errors with mathematical glyphs.
In my case evince displays a - " - instead of the - ≤ - glyph, it is very confusing.

I forgot to mention that it is just one example of those mathematical operators. Maybe evince can't distinguish the right format (utf, ascii, etc.)

Changed in poppler:
importance: Unknown → Medium
Changed in poppler:
importance: Medium → Unknown
Changed in poppler:
importance: Unknown → Medium
Maxim Levitsky (maximlevitsky) wrote :

Its very simple actually.
Fontconfig is just a mess.
It can happly pick up a preffered that misses glyphs that
document needs.

So to fix the '>=' issue I removed the 'ttf-symbol-replacement' font
which apparently isn't such a correct symbol replacement.

After that, fontconfig picked up as the Symbol font the
'/usr/share/fonts/X11/Type1/Symbol.pfb'

Which belongs to

maxim@maxim-laptop:~$ sudo dpkg -S /usr/share/fonts/X11/Type1/Symbol.pfb
xfonts-mathml: /usr/share/fonts/X11/Type1/Symbol.pfb

Hopefully, if you have that package installed the same will happen and the <= glyph will render normally again.

Now about some homeworks I had that were in hebrew, and were missing most Hebrew fonts
(like the one I attached here)

These files were using the Nimbus Roman No9 L to render most fonts and its very bad Times replacement, becuse it misses Hebrew glyphs.

I hoped to install MS fonts from 'ttf-mscorefonts-installer', but If you installed them in hope that you will get correct fonts, font-config won't pick these fonts.
There is a forest of setting files in /etc/fonts that make it select anything but not these fonts,

I just back-uped and removed the /usr/share/fonts/type1/gsfonts/ which contain that dreadful 'Nimbus Roman No9 L' font that replaces Times New Roman, and probably few more fonts and installed 'ttf-mscorefonts-installer' and now all my docs show up correctly (also with ttf-symbol-replacement, and 'Symbol' isn't mapped to MS font, but the one I told above seems to work fine)

The point it that these replacements don't contain nearly as much glyphs as needed unlike MS fonts and fonconfig isn't smart enough to pick _any_ font that has these glyphs. I am not picky about fonts, I just need to be able to read the document, in this case in Hebrew.

Instead of MS fonts, you can use the Dejavu fonts at least which are installed, and once again fontconfig doesn't pick them.
These fonts have good Unicode coverage, but still don't render everything correctly, in that old homework.
Once again to let these fonts to be used you need to apply some magic to /etc/fonts.
(They seems to be used if I just remove the /usr/share/fonts/type1/gsfonts/ and the MS fonts)

Changed in poppler (Ubuntu):
status: Triaged → Invalid
Maxim Levitsky (maximlevitsky) wrote :

And note that I used KDE's okular to find out which fonts were actually used as evince of course doesn't report that.

Hi guys.

I solved the problem by adding ArialMT->Arial alias to /etc/fonts/conf.avail/30-metric-aliases.conf. I attached the patch.

Attached the patch which adds ArialMT alias to /etc/fonts/conf.avail/30-metric-aliases.conf, that is fontconfig-config package. I tested it on PDF document without ArialMT subset included and it works fine.

Please consider committing the patch to upstream ASAP.

The attachment "ArialMT fix" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

tags: added: patch
Changed in fontconfig (Ubuntu):
status: New → Confirmed

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/poppler/poppler/issues/210.

Changed in poppler:
status: Confirmed → Unknown
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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