1928458 - PDF browsing font issue

Status: VERIFIED FIXED

(Firefox :: PDF Viewer, defect, P1)

Description

[faeldihn]

Attachment: Bug-FF-fonts.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:132.0) Gecko/20100101 Firefox/132.0

Steps to reproduce:

On my Win10pro, FireFox v132.0, I simply opened different official PDF documents received by mail from distinct administrations, browsing them in FF as I always did.

Actual results:

The same happens since at least 6 versions of FF now. Some of the rather common fonts used are messily displayed. Looking nothing like they appear in other PDF browsing tools. In the latest version, the fonts appeared correctly at first but a simple zooming on the document brought back the messy font display, even when zoomed back at 100%.

Expected results:

Simply have the same appearence as expected for each font, whatever the PDF file, and whatever zoom factor used.

Comment 1

[Negritas Sergiu, Desktop QA]

Hello! Thank you for submitting this issue I have tried to reproduce the issue on my end but unfortunately I wasn't able to with firefox 134.0a1(2024-11-06) on Windows 10 and MacOS 15 .
Could you please answer the following questions in order to further investigate this issue?

1. Does this issue happen with a new profile? Here is a link on how to create one: https://support.mozilla.org/en-US/kb/profile-manager-create-emove-switch-firefox-profiles
2. Does this issue happen in the latest nightly? Here is a link from where you can download it: https://www.mozilla.org/en-US/firefox/channel/desktop/
3. Do you have any addons installed? If yes could you please list them?

Comment 2

[Calixte Denizet (:calixte)]

:jfkthame, did you already see something like that before ?

Comment 3

[Jonathan Kew [:jfkthame]]

No, that doesn't look like something I've seen. From the screenshot & description, it kinda looks to me like a graphics-driver or webrender issue, or something around that level.

Lee, any thoughts on how we'd end up with such garbled glyphs in the pdf.js canvas?

Comment 4

[faeldihn]

Attachment: Bug-FF-fonts_2.png

Screenshot with latest FF nightly on the left with weird font text selected and div details in debugger, CG drivers and usual Calibri display in two other apps.

Comment 5

[faeldihn]

Hi,

1. I never used any firefox profile, I had to create an account to report this bug and the link you provided ends up 404, so I don't know if I misunderstood something by "profile".
2. I have tested with the nightly DLd from the link you just provided, without any addon, and yes, I have the bug, even after updating my GC drivers. See image joined with nightly window on the left. I selected the text and checked in the FFn debugger the font type and it looks like Calibri that is correctly displayed in other apps.
3. Active addons in my FF are [BlockTube, DuckDuckGo Privacy Esssentials, Search by Image, uBlock Origin]
   Inactive ones are [Adblock Plus, Firebug]

Comment 6

[Jonathan Kew [:jfkthame]]

(In reply to faeldihn from comment #4)

Created attachment 9435908 [details]
Bug-FF-fonts_2.png

Screenshot with latest FF nightly on the left with weird font text selected and div details in debugger, CG drivers and usual Calibri display in two other apps.

Just to clarify, the "bad" display there may not necessarily involve the Calibri font. What you see in the Firefox dev tools relates to an invisible text layer that pdf.js uses to handle text selection, search, etc., but the actual display is being drawn to a separate <canvas> element, probably using font resources that were embedded in the PDF.

If you have an example PDF file where this problem happens, and can attach it to this report, that would help us investigate what type of font is involved in the display. (I realize that might be a problem if these are PDFs that include personal account details -- is there perhaps a page that doesn't have any sensitive information?)

Comment 7

[faeldihn]

Attachment: Bug-FF-fonts_3.png

Hi again,

Just after opening the file, the fonts display just fine, but here's what I get when opening the PDF (I'll send next) with the FF Nightly after zooming out and in once.

Comment 8

[faeldihn]

Attachment: clp-mentions-danger.pdf

The PDF file relating to the last screenshot.

Comment 9

[Jonathan Kew [:jfkthame]]

Thank you. Interesting -- that PDF, at least, is not using an embedded font resource, it's simply using the installed version of Arial. But I can't reproduce this problem on my Windows machine, using either the release version of Firefox (132) or a Nightly (134) build.

It's odd that only the Regular face of Arial seems to be affected in your screenshot; the headings that use Arial Bold look fine.

Something about your system must be triggering this, in a way that doesn't happen on mine. Possibly some kind of graphics driver bug? Can you check whether any updated drivers for your graphics card may be available?

Another thing to check, although I don't quite see how it would cause this: do you have an extra copy of the Arial font installed somewhere? If there are several versions of the "same" font, maybe that leads to some kind of confusion/corruption. If you look in Windows Settings / Fonts at the Arial font family, do the standard faces (Regular/Bold/Italic/BoldItalic) all show the same version data? Are there duplicate copies of any faces?

Comment 10

[faeldihn]

As you can see in Bug-FF-fonts_2.png, I just installed the latest GC drivers just before testing on the latest nightly. I can't get more up to date.
If it was a driver issue, I guess the issue would be visible on FontTable and XChange viewer too but they don't.

I have no alternate Arial nor Calibri font files anywhere the Arial* search looked at, and why would only FF and FFnightly find these instead of the ones installed?
I have an ArialBlack but it's labelled ArialBlack and not Arial, and it looks like a small bold arial font but neat and clean, perfectly readable, not the oozy characters we get with the bug.

BTW, one point I'm most surprised by is the fact that sometimes, it doesn't appear bugged AT FIRST on opening, and that zooming back and forth changes the look to the bugged one and doesn't set it back clean.

Comment 11

[Calixte Denizet (:calixte)]

Attachment: image.png

Could you follow the steps as described in:
https://bugzilla.mozilla.org/show_bug.cgi?id=1854090#c23

I followed them with your pdf and you can see the result on the attached screenshot.
With my setup (Windows 11), pdf.js is fallbacking on Arial because ArialMT isn't embedded in the pdf.

Comment 12

[faeldihn]

Attachment: Bug-FF-fonts_4.png

I found the font used: Mermaid Pudgy used with a bad horizontal spacing.
(see the last attached file)

Removing this font would force the browser to use another one that is readable and the bug would pass unnoticed, but it's not a proper solution IMHO (FYI, I started BO/FO dev in 1981 and stopped 2 years ago).

I think I understand what you suspect, but in this case:

1. how do Acrobat Reader, PDF XChange Viewer and even LibreOffice Draw find a correct replacement font that is precisely the same, for the official documents like for the one I sent as last attachement?
2. and, if replacing the missing embedment is the solution they all adopted, why isn't it also applied by FF's PDF reader too?
   Is there a default font defined in the viewer.css used by FF and always available to use as replacement for missing ones?

Best regards.

Comment 13

[Jonathan Kew [:jfkthame]]

Oh, wow! Not what I was expecting, but thank you for finding and reporting this.

The underlying issue is the metadata in this "Mermaid Pudgy" font. I found it available from various font-download sites (e.g. fonts2u.com), and took a look. The 'name' table, when dumped with the TTX tool, shows:

  <name>
    <namerecord nameID="0" platformID="0" platEncID="0" langID="0x0">
      Mermaid Pudgy Font (C) 1998 John A. Matheson. May be used for personal purposes. May not be redistributed or reposted without the express permission of the above.
    </namerecord>
    <namerecord nameID="1" platformID="0" platEncID="0" langID="0x0">
      Mermaid Pudgy
    </namerecord>
    <namerecord nameID="2" platformID="0" platEncID="0" langID="0x0">
      Regular
    </namerecord>
    <namerecord nameID="3" platformID="0" platEncID="0" langID="0x0">
      Monotype:Arial Regular:Version 1 (Microsoft)
    </namerecord>
    <namerecord nameID="4" platformID="0" platEncID="0" langID="0x0">
      Mermaid Pudgy
    </namerecord>
    <namerecord nameID="5" platformID="0" platEncID="0" langID="0x0">
      MS core font:V1.00
    </namerecord>
    <namerecord nameID="6" platformID="0" platEncID="0" langID="0x0">
      ArialMT
    </namerecord>
    <namerecord nameID="0" platformID="1" platEncID="0" langID="0x0" unicode="True">
      Mermaid Pudgy Font (C) 1998 John A. Matheson. May be used for personal purposes. May not be redistributed or reposted without the express permission of the above.
    </namerecord>
    <namerecord nameID="1" platformID="1" platEncID="0" langID="0x0" unicode="True">
      Mermaid Pudgy
    </namerecord>
    <namerecord nameID="2" platformID="1" platEncID="0" langID="0x0" unicode="True">
      Regular
    </namerecord>
    <namerecord nameID="3" platformID="1" platEncID="0" langID="0x0" unicode="True">
      Monotype:Arial Regular:Version 1 (Microsoft)
    </namerecord>
    <namerecord nameID="4" platformID="1" platEncID="0" langID="0x0" unicode="True">
      Mermaid Pudgy
    </namerecord>
    <namerecord nameID="5" platformID="1" platEncID="0" langID="0x0" unicode="True">
      MS core font:V1.00
    </namerecord>
    <namerecord nameID="6" platformID="1" platEncID="0" langID="0x0" unicode="True">
      ArialMT
    </namerecord>
    <namerecord nameID="0" platformID="3" platEncID="1" langID="0x409">
      Mermaid Pudgy Font (C) 1998 John A. Matheson. May be used for personal purposes. May not be redistributed or reposted without the express permission of the above.
    </namerecord>
    <namerecord nameID="1" platformID="3" platEncID="1" langID="0x409">
      Mermaid Pudgy
    </namerecord>
    <namerecord nameID="2" platformID="3" platEncID="1" langID="0x409">
      Regular
    </namerecord>
    <namerecord nameID="3" platformID="3" platEncID="1" langID="0x409">
      Monotype:Arial Regular:Version 1 (Microsoft)
    </namerecord>
    <namerecord nameID="4" platformID="3" platEncID="1" langID="0x409">
      Mermaid Pudgy
    </namerecord>
    <namerecord nameID="5" platformID="3" platEncID="1" langID="0x409">
      MS core font:V1.00
    </namerecord>
    <namerecord nameID="6" platformID="3" platEncID="1" langID="0x409">
      ArialMT
    </namerecord>
  </name>

Note how some of the 'name' records identify it as being Arial or ArialMT, and as an "MS core font" (which it definitely isn't).

In particular, name ID 6, the "PostScript name", is supposed to be unique to the font, and if there are multiple fonts with the same PostScript name then problems can be expected. In this case, the PostScript name is ArialMT, which is the same as the "real" Arial font from Monotype, and so there's a risk that when software (such as a postscript printer, but also potentially other software -- such as a web browser rendering a PDF file) tries to access a particular font, it may get a different one that shares the same identifier, perhaps in a consistent way or perhaps even "at random".

Name ID 3 is also supposed to be a "unique identifier", but is clearly an unchanged copy of what the original Arial font contained. I guess the creator started with a copy of Arial, modified the glyph shapes and some of the naming data, but didn't really know what they were doing and left it in this inconsistent state.

So the problem here isn't that the font needed for the PDF is "missing". The PDF simply asks for ArialMT. The problem is that your system has (or had) two fonts installed that both claim to be "ArialMT" but have quite different glyph designs -- the real "Arial", and this "Mermaid Pudgy" -- and sometimes we may get the "wrong" one.

Comment 14

[Calixte Denizet (:calixte)]

For this missing font (ArialMT) we search for one of the font in the list:

local(ArialMT),local(Helvetica),local(Helvetica Neue),local(Arial),local(Arial Nova),local(Liberation Sans),
local(Arimo),local(Nimbus Sans),local(Nimbus Sans L),local(A030),local(TeX Gyre Heros),local(FreeSans),
local(DejaVu Sans),local(Albany),local(Bitstream Vera Sans),local(Arial Unicode MS),
local(Microsoft Sans Serif),local(Apple Symbols),local(Cantarell),
url(resource://pdf.js/web/standard_fonts/LiberationSans-Regular.ttf)

So we really try to find a good fallback...
From the js perspective, we don't have a better way (afaik) to find a better fallback (except in adding some names to the list).

:jfkthame don't we have a way/trick to guess when a font is likely not what it pretends to be ?

Comment 15

[faeldihn]

How does LibreOffice Draw solve the question? Since it seems to never be confused with it and is open source, there may be some way to find hoiw it copes with such mixed identities in fonts.

Comment 16

[Jonathan Kew [:jfkthame]]

(In reply to Calixte Denizet (:calixte) from comment #14)

For this missing font (ArialMT) we search for one of the font in the list:

local(ArialMT),local(Helvetica),local(Helvetica Neue),local(Arial),local(Arial Nova),local(Liberation Sans),
local(Arimo),local(Nimbus Sans),local(Nimbus Sans L),local(A030),local(TeX Gyre Heros),local(FreeSans),
local(DejaVu Sans),local(Albany),local(Bitstream Vera Sans),local(Arial Unicode MS),
local(Microsoft Sans Serif),local(Apple Symbols),local(Cantarell),
url(resource://pdf.js/web/standard_fonts/LiberationSans-Regular.ttf)

So we really try to find a good fallback...
From the js perspective, we don't have a better way (afaik) to find a better fallback (except in adding some names to the list).

This isn't really about a "fallback", even: the PDF specifies ArialMT, and so the first thing we look for according to that list is exactly that: the font with the PostScript name "ArialMT". If we didn't find one, then Helvetica, Nimbus, etc., would be fallbacks, but this is (apparently) exactly the font that the PDF asks for. So adding names to a list won't help: we're already finding the exact name that was requested.

Note that the CSS Fonts spec explicitly says that src: local(...) matches PostScript names:

For OpenType and TrueType fonts, this string is used to match only the Postscript name or the full font name in the name table of locally available fonts.

The PDF document identifies the font to be used by PostScript name, so looking it up via src: local(...) and finding an installed font with exactly that PS name is a completely reasonable thing to do. We can't locate "ArialMT" by full name (the other possible identifier usable in src: local(...)) because there is no font with that as its full name; the full name of the regular face of the Arial family is simply "Arial", but that is not what the PDF specifies.

:jfkthame don't we have a way/trick to guess when a font is likely not what it pretends to be ?

Not really. I suppose we could try to identify the situation where there are multiple fonts claiming the same identity (which is what's happening here), and try to come up with some heuristics to decide which of the candidates to prefer, instead of picking one "at random". But fundamentally if there are two font resources that both call themselves "PostScript-name-X", and the content asks for a font with that name, we cannot be sure which is the "right" resource to use.

This is a bit like the issue we saw in bug 1854090, where some Acrobat software was polluting the system with re-encoded copies of Arial or other standard fonts (without modifying the PSname), and then our requests (via pdf.js src: local(...) lookups) for Arial might end up using a garbled resource. In that case, we've worked around the issue by looking for the .tmp suffix on the family name and omitting such fonts from PSname lookup.

The case here is trickier, as there's no clear "marker" on the font (like the .tmp suffix) that indicates "I'm not to be trusted", but maybe we can devise some usable heuristic.

(In reply to faeldihn from comment #15)

How does LibreOffice Draw solve the question? Since it seems to never be confused with it and is open source, there may be some way to find hoiw it copes with such mixed identities in fonts.

I expect it is selecting fonts using family name and style (like Firefox does when displaying HTML content). That "Mermaid Pudgy" font does have a family name distinct from Arial, so there's no confusion there.

Comment 17

[Calixte Denizet (:calixte)]

A STR for this bug:

• install the font Mermaid Pudgy;
• run Firefox;
• open the attached pdf.

The text in the table on the first page should looks "normal" (not "puffy").

To fix this bug, we'll just replace local(ArialMT) with local(Arial).

Comment 18

[BMO Github Automation]

Attachment: [mozilla/pdf.js] Alias ArialMT with Arial when ArialMT isn't embedded (bug 1928458) (#19014)

Comment 19

[Jonathan Kew [:jfkthame]]

(In reply to Calixte Denizet (:calixte) from comment #17)

A STR for this bug:

• install the font Mermaid Pudgy;
• run Firefox;
• open the attached pdf.

The text in the table on the first page should looks "normal" (not "puffy").

To fix this bug, we'll just replace local(ArialMT) with local(Arial).

I'm not sure we should rush into that as a workaround. ArialMT is the most correct name to use here; and the problem isn't limited to "ArialMT" (that's just the example we happen to see here). If the "guilty" user-installed font happened to come with a bold face as well as regular, that would probably break "Arial-BoldMT" in the same way; and similarly if someone has a font that's a hacked-and-improperly-renamed version of something else like Courier or Times New Roman, the same issue could arise.

I'm just testing a possible patch for Gecko that should make it more reliably choose the "right" font in cases like this, by comparing the PSname (which the user doesn't normally see) and the family name (which is what's exposed to users, and therefore what inexpert font hackers tend to change, while neglecting other names), and preferring the font where the PSname and family name are more similar.

Comment 20

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1928458 - Make local font name lookup prefer face [postscript/full] names that are more similar to their family name, in case of duplicates.. r=#layout

Comment 21

[faeldihn]

In the correction checking, don't forget that on some FF run, the PDF opening primarily looks fine, but that zooming in and out brings the wrong font and never allows to recover the initial good appearance.

Comment 22

[Jonathan Kew [:jfkthame]]

That's because of lazy-loading of font name data. If we haven't yet loaded all the local font names when the page is first displayed, you may get the "right" font (because it's the first one we find that matches). But then once all fonts have had their names initialized, the "wrong" font has superseded it and gets used in any subsequent rendering.

The fix here will prevent that happening because it will recognize that the "right" font has more consistent naming and so will prefer it, and ignore the subsequently-loaded Mermaid font with its bad name data.

Comment 23

[blinky]

Regression range:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ffee8e3a7870875ab78af162638548f72cdabddf&tochange=375c5940c253b38f65792c847de04bc50b990b22

Regressed by: bug 1832514

Comment 24

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/030412276e15
Make local font name lookup prefer face [postscript/full] names that are more similar to their family name, in case of duplicates.. r=dshin

Comment 25

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/030412276e15

Comment 26

[Monica Chiorean]

I was able to reproduce the issue on Win11x64 using Firefox build 132.0a1(20240904095513) and steps from comment #17.
Verified as fixed on Win11x64 using Firefox build 134.0b2 and 135.0a1(20241128215411).