1766039 - Poor font rendering when viewing some documents in pdf.js on Linux

Status: VERIFIED FIXED

(Firefox :: PDF Viewer, defect, P1)

Description

[Botond Ballo [:botond]]

Attachment: PDF rendering in Firefox Nightly

STR

Load https://www.tcc-cci.gc.ca/Content/assets/forms/base/general_motion_form65_e.pdf in Firefox Nightly on Linux. Tested using Debian 10.

Actual results

Poor font rendering, with the letters being cramped and in some cases slightly overlapping, as shown in the attached screenshot.

Expected results

PDF renders as it does in a non-browser PDF viewer.

Comment 1

[Botond Ballo [:botond]]

Attachment: PDF rendering in Okular

As a point of comparison, here is how the PDF renders in Okular (the default PDF viewer in the KDE desktop environment) on the same system.

Comment 2

[Botond Ballo [:botond]]

Attachment: PDF rendering in Firefox 78

Finally, here is how the PDF renders in Firefox 78 on the same system. It's still not as nice as Okular (the letters are taller than they should be), but at least they are not overlapping, so the rendering has regressed on the Firefox side since then.

Comment 3

[Botond Ballo [:botond]]

(In reply to Botond Ballo [:botond] from comment #2)

Finally, here is how the PDF renders in Firefox 78 on the same system. It's still not as nice as Okular (the letters are taller than they should be), but at least they are not overlapping, so the rendering has regressed on the Firefox side since then.

Regression range:

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c6d819bd39daf86acd5e0c5bce5d74c2db8b8d64&tochange=bdc02548880557ac7a7d9023e6cadc0c8a44a2b5

I'm guessing "Bug 1686102 - Update pdf.js to version 2.7.510. r=bdahl"?

Comment 4

[Botond Ballo [:botond]]

(In reply to Botond Ballo [:botond] from comment #3)

Regression range:

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c6d819bd39daf86acd5e0c5bce5d74c2db8b8d64&tochange=bdc02548880557ac7a7d9023e6cadc0c8a44a2b5

I'm guessing "Bug 1686102 - Update pdf.js to version 2.7.510. r=bdahl"?

Assuming that's the regressing change, changing component to PDF Viewer. Not sure if there's some way to bisect among pdf.js commits themselves.

Comment 5

[Jonathan Kew [:jfkthame]]

The pdf.js rendering is showing a completely different font from the Okular screenshot. This PDF appears to use Times (actually, TimesNewRomanPSMT, which IIRC is the psname of the Times New Roman shipped on Windows, for example), but does not actually embed the font; it relies on the viewer/renderer having support for the "standard" PDF fonts (Times, Helvetica, Courier, etc) built in.

I'm guessing your Debian system doesn't have a Times font, so we get whatever substitution fontconfig offers, and that doesn't work well because it doesn't match the glyph metrics of Times that were used to lay out the text.

Comment 6

[Botond Ballo [:botond]]

(In reply to Jonathan Kew (:jfkthame) from comment #5)

I'm guessing your Debian system doesn't have a Times font,

Hmm, I do get "Times New Roman" as an option when choosing font in e.g. Kate.

Comment 7

[Jonathan Kew [:jfkthame]]

Interesting. In that case it seems surprising that it doesn't get used by pdf.js here, but the glyphs in your screenshots are most definitely not TNR glyphs. Maybe there's an issue with how pdf.js takes the name requested by the PDF and tries to access it on the local system.

What does fc-match -v :family="Times New Roman" show? Curious what names it exposes.

Comment 8

[Botond Ballo [:botond]]

Attachment: Output of `fc-match -v :family="Times New Roman"`

(In reply to Jonathan Kew (:jfkthame) from comment #7)

What does fc-match -v :family="Times New Roman" show? Curious what names it exposes.

Attached the output of this

Comment 9

[Jonathan Kew [:jfkthame]]

Thanks. AFAICS, that looks like exactly the expected font.

I don't know how pdf.js goes about accessing installed fonts, but to check whether there's anything weird about the fontconfig setup that might be interfering, could you try the two examples

data:text/html,<div style="font:40px Times New Roman,monospace">Hello world

data:text/html,<style>@font-face{font-family:x;src:local("TimesNewRomanPSMT")}</style><div style="font:40px x,monospace">Hello world

and see what they render? They should both use your installed TNR.

Note that while the "regression" range in comment 3 is interesting -- it seems something about how pdf.js handles the font has changed there -- the Firefox 78 rendering as shown in comment 2 was not using the correct font either. The glyphs there are definitely not Times; they look to me like they're probably DejaVu Serif or something closely related to that.

Comment 10

[Calixte Denizet (:calixte)]

The font name is changed to Times and it's likely the root cause of the issue here.
We should use the name as it is in the pdf and possibly fallback on an embedded standard font when the font cannot be found on the system.

Comment 11

[Botond Ballo [:botond]]

Attachment: Rendering of example pages in comment 9

(In reply to Jonathan Kew (:jfkthame) from comment #9)

to check whether there's anything weird about the fontconfig setup that might be interfering, could you try the two examples

data:text/html,<div style="font:40px Times New Roman,monospace">Hello world

data:text/html,<style>@font-face{font-family:x;src:local("TimesNewRomanPSMT")}</style><div style="font:40px x,monospace">Hello world

and see what they render? They should both use your installed TNR.

They render the same. Looks like Times to me, but I attached a screenshot to be sure.

Comment 12

[Jonathan Kew [:jfkthame]]

Thanks. Yes, that's Times (New Roman). Good; that confirms there's nothing fundamentally interfering with Firefox finding and using it.
Per comment 10, it sounds pretty clear this is strictly a pdf.js issue; hopefully Calixte can come up with a fix there.

Comment 13

[GitHub Bugzilla PR Linker]

Attachment: Link to GitHub pull-request: https://github.com/mozilla/pdf.js/pull/14844

Comment 14

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1686102

Comment 15

[Ulrich Windl]

Attachment: Screenshot from Firefox 91.11.0 ESR (openSUSE Leap 15.4)

Unsure whether this is the same bug (viewing https://cscie92.dce.harvard.edu/spring2021/Microsoft%20Extensible%20Firmware%20Initiative%20FAT32%20File%20System%20Specification,%20Version%201.03,%2020001206.pdf), but there seem kind of arbitrary font changes (wrong font being used). PDF creator was Microsoft Word 2002. Some fonts seem to be partially embedded, while others are not.

Comment 16

[Ulrich Windl]

Attachment: Screenshot from Evince 41.3 running on the same machine and OS

When viewing the same portion of the document in Evince, the fonts seem to display correctly.

Comment 17

[Darko Veberic]

the same bug also reported in pdf.js github https://github.com/mozilla/pdf.js/issues/15317

Comment 20

[BMO Github Automation]

Attachment: [mozilla/pdf.js] Use a local font or fallback on an embedded one (if it exists) for non-embedded fonts (bug 1766039) (#16363)

Comment 21

[Botond Ballo [:botond]]

\o/ Thanks very much Calixte & Jonas for your work on this!

Comment 26

[Monica Chiorean]

I tried multiple builds 78.0, 86.0a1, 91.11.0esr but I could not reproduce the issue on Ubuntu 20.04.
Reporter, can you please confirm issue is fixed on latest Nightly build 116.0a1 (https://archive.mozilla.org/pub/firefox/nightly/2023/06/2023-06-26-09-42-17-mozilla-central/) and latest Beta build 115.0b9 (https://archive.mozilla.org/pub/firefox/candidates/115.0b9-candidates/build1/linux-x86_64/en-US/). Thank you very much.

Comment 27

[Botond Ballo [:botond]]

Confirmed that the issue is fixed in the builds from comment 26.

Comment 28

[Monica Chiorean]

Mark issue as verified based on comment#27.