1746707 - Inconsistent font rendering (text alternates between serif/sans-serif, bad kerning) in certain PDF

Status: REOPENED

(Firefox :: PDF Viewer, defect, P3)

Description

[Shadowfacts]

Attachment: PDF exhibiting broken behavior

This seems to happen with all PDFs published here: https://www.opn.ca6.uscourts.gov/opinions/opinions.php.

This bug is reproducible in Nightly build 20211217212339.

Steps to reproduce:

1. Open the PDF at https://www.opn.ca6.uscourts.gov/opinions.pdf/21a0287p-06.pdf (archived copy attached) in the built-in viewer
2. View page 5 (the issue is present on all pages, but is most obvious in the main text of the document)

Expected behavior:
The PDF renders normally, with only the serifed font and consistent kerning, as happens in Chrome and macOS's Preview.app.

Actual behavior:
Text alternates between serifed and sans-serifed fonts, and text that appears sans-serif has very inconsistent kerning.

Comment 1

[Kenan]

I cannot reproduce it with Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:97.0) Gecko/20100101 Firefox/97.0 Build: 20211217212339

I assume you are using MacOS?
Can you copy the version string (in about:support) containing your OS version and have a look if there is a console output ?

Comment 2

[Shadowfacts]

Attachment: Screenshot of PDF exhibiting broken behavior

Comment 3

[Shadowfacts]

My user agent is Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:95.0) Gecko/20100101 Firefox/95.0, but the macOS version is actually 12.1 and I'm on arm64. There aren't any errors in the web inspector console on the PDF viewer page.

I've also attached a screenshot of what I'm seeing.

Comment 4

[Peter Magyari (Desktop QA)]

I wasn't able to reproduce this on MacOS 11 or m1 (arm) MacOS 11.6 either.

Could you check if this also occurs while using a new profile? Here is a link to help you with that:
https://support.mozilla.org/en-US/kb/profile-manager-create-remove-switch-firefox-profiles

Thank you!

Comment 5

[Shadowfacts]

I was able to repro this on both a new profile in Stable (95.0.1) and a new profile on the aforementioned Nightly build.

Comment 6

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

The severity field is not set for this bug.
:bdahl, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 7

[Brendan Dahl [:bdahl]]

I was unable to reproduce on MacOS 11.6, but a coworker could reproduce on 12.0.1. This seems to be a regression from monterey.

@shadowfacts,
Have you run into this issue with other PDFs?

Comment 9

[Shadowfacts]

I'm able to reproduce it for every PDF published by the US 6th Circuit (https://www.opn.ca6.uscourts.gov/opinions/opinions.php) but not with any other PDFs I've tested/encountered. I assume it's related to some idiosyncrasy in how the court is generating those PDFs from whatever source files.

Comment 10

[AM]

every Latex generated document that I have tried also suffers, eg Arxiv
https://arxiv.org/pdf/1607.03188.pdf

macos 12.1

In fact 90% of documents that I look at do not work in a university environment

Comment 11

[quantugie]

I can also reproduce this problem with Monterey and Firefox 96.0.2. This also affects many UN documents, e.g. http://daccess-ods.un.org/access.nsf/Get?Open&DS=A/HRC/WG.6/36/USA/1&Lang=E https://undocs.org/A/HRC/RES/48/13. It might be related to this bug: https://github.com/mozilla/pdf.js/issues/13176.

Comment 12

[Marco Castelluccio [:marco]]

(In reply to quantugie from comment #11)

I can also reproduce this problem with Monterey and Firefox 96.0.2. This also affects many UN documents, e.g. http://daccess-ods.un.org/access.nsf/Get?Open&DS=A/HRC/WG.6/36/USA/1&Lang=E https://undocs.org/A/HRC/RES/48/13. It might be related to this bug: https://github.com/mozilla/pdf.js/issues/13176.

https://github.com/mozilla/pdf.js/issues/13176 appears to be a regression.
Can any of you who can reproduce try to find out if this bug is a regression too? You can use mozregression.

Comment 13

[AM]

I ran mozregression,

everything works, the pdf's are correct

however, when I run ff96 in "troubleshooting" mode the pdf's are bad.

Are there other forms of corruption of profile that are possible? Different font paths....

Comment 14

[AM]

Found it:

If I change my "default zoom" to 100% all is good
"default zoom" 120% bad pdf

Comment 15

[quantugie]

I've yet to run mozregression, but AM's solution doesn't work for me. "Default zoom" in the settings (and zoom in PDF.js) are at 100% but the issue remains, e.g. in this document https://undocs.org/A/HRC/RES/48/13

Comment 16

[AM]

I tried the document of quantugie:

Indeed 100% setting still gives problems, even if it fixes latex documents.

running mozregression again gives perfect rendering, so it seems to be linked to different options in the profile

Comment 17

[Shadowfacts]

I'm able to reproduce the issue in quantugie's UN document as well but not in AM's one on arXiv. And it happens regardless of zoom level.

This issue appears to be specific to ARM64. Launching firefox under Rosetta (by checking "Open in Rosetta" in the Get Info panel for Firefox.app in Finder) and visiting a problematic PDF does not exhibit the issue.

Using mozregression, I was able to reproduce the issue all the way back to Nightly 2020-11-13, which I believe to be the first Apple Silicon-native build. Note that using mozregression-gui always launches FF under Rosetta, so you have to use mozregression from the command line.

Comment 18

[AM]

I played some more. To mess up the arxiv rendering I find I need TWO settings

set "default zoom" 120%

set privacy.resistFingerprinting to "true"

This indeed on a ARM build of firefox.

I also tried on an Intel mac, same OS level [12.2], same Firefox release [96.0.3].
This always renders correctly, even with these variables changed

Comment 20

[quantugie]

Just to clarify that privacy.resistFingerprinting is set to false and the bug nonetheless occurs on Mac OS with e.g. the UN documents. Meanwhile, I have no issues with the Arxiv document linked above (likely because the two conditions outlined aren't present for me).

Comment 21

[AM]

Note, it is not like 1582021, things are not "blurry", it looks like a wrong font is substituted, or the calculation of kerning has gone totally wrong. This on the UN documents, or the arxiv with the "wrong" settings