Closed Bug 1839860 Opened 2 years ago Closed 1 year ago

Broken font rendering in Nightly PDF preview

Categories

(Firefox :: PDF Viewer, defect, P3)

Product:
Firefox
Component:
PDF Viewer
Version:
Firefox 116
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: rverschelde, Unassigned)

References

(Regression)

Details

(Keywords: regression)

Attachments

(3 files)

broken-pdf-firefox-nightly-116.png
126.38 KB, image/png
Details
broken-pdf-firefox-release-114.png
127.88 KB, image/png
Details
Godot-US-Trademark.pdf
484.84 KB, application/pdf
Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/116.0

Steps to reproduce:

In current Firefox Nightly on Linux (116.0a1 (2023-06-22) (64-bit), Mozilla provided tarball), PDF preview seems to render some fonts wrong on a specific document.

The document is publicly accessible here: https://tsdr.uspto.gov/documentviewer?caseId=sn90175204&docId=ORC20230507023913#docIndex=0&page=1

Also attached for testing.

In Firefox 114.0.2 (Mozilla provided tarball) and Firefox ESR 102.12.0 (Mageia Linux distro package), it renders fine. Likewise in latest Chromium.

The attached screenshots show the output in Nightly and FF 114 respectively.

Attached file Godot-US-Trademark.pdf —

The PDF in question.

Note that the PDF reader Okular on Linux reports:

  • This document has forms. Click on the button to interact with them, or use View -> Show Forms.
  • This document is digitally signed. There have been changes since last signed.

The forms/digital signature might have an impact on how PDF.js handles it.

I haven't noticed such rendering bugs with other PDFs recently.

The Bugbug bot thinks this bug should belong to the 'Firefox::PDF Viewer' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → PDF Viewer

Could you open the devtools console (ctrl+shift+K) and report what you've inside ?

Sure, from the locally downloaded PDF:

Partitioned cookie or storage access was provided to “file:///home/akien/Downloads/Godot-US-Trademark.pdf” because it is loaded in the third-party context and dynamic state partitioning is enabled.

Warning: Invalid absolute docBaseUrl: "file:///home/akien/Downloads/Godot-US-Trademark.pdf". pdf.worker.js:985:13
PDF 3405e8635e3fd573981fdaf67a3da06c [1.7 iText® 5.5.14-SNAPSHOT ©2000-2018 iText Group NV (AGPL-version); modified using iText® 5.5.14-SNAPSHOT ©2000-2018 iText Group NV (AGPL-version) / -] (PDF.js: 3.8.83 [46b8f9e2f]) viewer.js:1494:13
Warning: Digital signatures validation is not supported viewer.js:1517:15
Warning: Knockout groups not supported.

The fonts Times-Roman isn't embedded in your pdf, hence we fallback on a system font.
For this one we try to load:
local(Times New Roman),local(Times-Roman),local(Times),local(Liberation Serif),local(Nimbus Roman),local(Nimbus Roman L),local(Tinos),local(Thorndale),local(TeX Gyre Termes),local(FreeSerif),local(DejaVu Serif),local(Bitstream Vera Serif),local(Ubuntu)

and in considering that there's nothing in your console, it means that one of these fonts is used.
Either you've on your system a font with one of these names which doesn't have the correct metrics or a font in this list is wrong (I mean it shouldn't be in this list because it doesn't have the same metrics as Times New Roman).
In using, for example fc-list "Times New Roman", you can check if this font is in your system, could you try this command in using the different names you've above (in the order they're) and tell us what's the first one available in your system ?

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

For more information, please visit BugBot documentation.

Flags: needinfo?(cdenizet)

In using, for example fc-list "Times New Roman", you can check if this font is in your system, could you try this command in using the different names you've above (in the order they're) and tell us what's the first one available in your system ?

:Rémi, could you answer to the question please ?

Flags: needinfo?(cdenizet) → needinfo?(rverschelde)

Sorry for the delay.

First I can confirm the issue is still reproducible in today's Nightly.

fc-list "Times New Roman" has no result, but fc-list "Times-Roman" does:

$ fc-list "Times-Roman"
/usr/share/fonts/75dpi/timBI12.pcf.gz: Times:style=Bold Italic
/usr/share/fonts/75dpi/timBI24-ISO8859-1.pcf.gz: Times:style=Bold Italic
/usr/share/fonts/75dpi/timR08.pcf.gz: Times:style=Regular
/usr/share/fonts/75dpi/timR10.pcf.gz: Times:style=Regular
/usr/share/fonts/75dpi/timR18.pcf.gz: Times:style=Regular
/usr/share/fonts/75dpi/timI12.pcf.gz: Times:style=Italic
/usr/share/fonts/75dpi/timR12-ISO8859-1.pcf.gz: Times:style=Regular
/usr/share/fonts/75dpi/timB24-ISO8859-1.pcf.gz: Times:style=Bold
/usr/share/fonts/75dpi/timR08-ISO8859-1.pcf.gz: Times:style=Regular
/usr/share/fonts/75dpi/timR10-ISO8859-1.pcf.gz: Times:style=Regular
/usr/share/fonts/75dpi/timR14-ISO8859-1.pcf.gz: Times:style=Regular
/usr/share/fonts/75dpi/timBI18.pcf.gz: Times:style=Bold Italic
/usr/share/fonts/75dpi/timBI08.pcf.gz: Times:style=Bold Italic
/usr/share/fonts/75dpi/timBI10.pcf.gz: Times:style=Bold Italic
/usr/share/fonts/75dpi/timB24.pcf.gz: Times:style=Bold
/usr/share/fonts/75dpi/timR12.pcf.gz: Times:style=Regular
/usr/share/fonts/75dpi/timI08.pcf.gz: Times:style=Italic
/usr/share/fonts/75dpi/timI10.pcf.gz: Times:style=Italic
/usr/share/fonts/75dpi/timI18.pcf.gz: Times:style=Italic
/usr/share/fonts/75dpi/timI24-ISO8859-1.pcf.gz: Times:style=Italic
/usr/share/fonts/75dpi/timB14.pcf.gz: Times:style=Bold
/usr/share/fonts/75dpi/timR24.pcf.gz: Times:style=Regular
/usr/share/fonts/75dpi/timR14.pcf.gz: Times:style=Regular
/usr/share/fonts/75dpi/timB18-ISO8859-1.pcf.gz: Times:style=Bold
/usr/share/fonts/75dpi/timBI24.pcf.gz: Times:style=Bold Italic
/usr/share/fonts/75dpi/timB12-ISO8859-1.pcf.gz: Times:style=Bold
/usr/share/fonts/75dpi/timB14-ISO8859-1.pcf.gz: Times:style=Bold
/usr/share/fonts/75dpi/timB08-ISO8859-1.pcf.gz: Times:style=Bold
/usr/share/fonts/75dpi/timB10-ISO8859-1.pcf.gz: Times:style=Bold
/usr/share/fonts/75dpi/timBI14-ISO8859-1.pcf.gz: Times:style=Bold Italic
/usr/share/fonts/75dpi/timBI08-ISO8859-1.pcf.gz: Times:style=Bold Italic
/usr/share/fonts/75dpi/timBI10-ISO8859-1.pcf.gz: Times:style=Bold Italic
/usr/share/fonts/75dpi/timB12.pcf.gz: Times:style=Bold
/usr/share/fonts/75dpi/timBI12-ISO8859-1.pcf.gz: Times:style=Bold Italic
/usr/share/fonts/75dpi/timBI14.pcf.gz: Times:style=Bold Italic
/usr/share/fonts/75dpi/timR24-ISO8859-1.pcf.gz: Times:style=Regular
/usr/share/fonts/75dpi/timI18-ISO8859-1.pcf.gz: Times:style=Italic
/usr/share/fonts/75dpi/timI24.pcf.gz: Times:style=Italic
/usr/share/fonts/75dpi/timBI18-ISO8859-1.pcf.gz: Times:style=Bold Italic
/usr/share/fonts/75dpi/timI12-ISO8859-1.pcf.gz: Times:style=Italic
/usr/share/fonts/75dpi/timI14.pcf.gz: Times:style=Italic
/usr/share/fonts/75dpi/timB18.pcf.gz: Times:style=Bold
/usr/share/fonts/75dpi/timI14-ISO8859-1.pcf.gz: Times:style=Italic
/usr/share/fonts/75dpi/timI08-ISO8859-1.pcf.gz: Times:style=Italic
/usr/share/fonts/75dpi/timI10-ISO8859-1.pcf.gz: Times:style=Italic
/usr/share/fonts/75dpi/timB08.pcf.gz: Times:style=Bold
/usr/share/fonts/75dpi/timB10.pcf.gz: Times:style=Bold
/usr/share/fonts/75dpi/timR18-ISO8859-1.pcf.gz: Times:style=Regular

This comes from Mageia's x11-font-adobe-75dpi-1.0.3-10.mga9 package whose upstream is https://xorg.freedesktop.org/releases/individual/font/font-adobe-75dpi-1.0.3.tar.bz2

I noticed 1.0.3 is from 2010 and there's been a 1.0.4 release in March 2023, I'll try it out.

Still, this low dpi font sounds like a pretty bad match.

Flags: needinfo?(rverschelde)

I noticed 1.0.3 is from 2010 and there's been a 1.0.4 release in March 2023, I'll try it out.

Same issue with 1.0.4.

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

For more information, please visit BugBot documentation.

Flags: needinfo?(cdenizet)
Duplicate of this bug: 1845551
Keywords: regression
Regressed by: 1832514

I setup each rpm:

  • x11-font-adobe-75dpi
  • x11-font-adobe-100dpi

on my Fedora and in both cases it looks awful.
The glyphs are overlapping because their metrics as defined in those packages are not the same as the ones we've in the pdf.
So these fonts are very likely not the ones we expect to have.
I opened the pdf in Evince and in despite of the presence of this Times font, Nimbus is used.
That said, according to https://packages.gentoo.org/packages/media-fonts/font-adobe-100dpi, those adobe fonts are bitmap fonts and are maybe not the most appropriate way to nicely render some text.
Maybe we can change the order of the fonts in the list of possible substitution... but what should we do in case someone has a "wrong" Nimbus ??

Flags: needinfo?(cdenizet)

That said, when I'll have some time I'll try to figure out something to check if a substitution is good enough.
For now, the problem can likely be fixed on your side in using fontconfig or whatever solution.

Severity: -- → S3
Priority: -- → P3

A possible way to improve the situation for the standard fonts could be:

  • to load the font in the worker
  • get the widths of one or two glyphs
  • compare to what we expect to have
  • and if it isn't good enough then move the substitution to the end of the list.

Thank you very much for looking into this.

Can I patch the Firefox 115.0.3 in some way to restore the old behavior or change the behavior to use the Nimbus font, available in our distribution?

$ pdffonts ~/Downloads/7058051_90175204_052323_ORC.pdf
name                                 type              encoding         emb sub uni object ID
------------------------------------ ----------------- ---------------- --- --- --- ---------
Times-Bold                           Type 1            WinAnsi          no  no  no       7  0
Times-Roman                          Type 1            WinAnsi          no  no  no       8  0
Times-BoldItalic                     Type 1            WinAnsi          no  no  no      19  0
Times-Roman                          Type 1            WinAnsi          no  no  no      16  0

I am unable to reproduce the problem of this bug reporter, despite having Times-* fonts installed.

$ fc-list Times-Roman
/usr/share/fonts/X11/75dpi/timB08.pcf.gz: Times:style=Bold
/usr/share/fonts/X11/75dpi/timB10.pcf.gz: Times:style=Bold
/usr/share/fonts/X11/75dpi/timBI12.pcf.gz: Times:style=Bold Italic
/usr/share/fonts/X11/100dpi/timR24-ISO8859-1.pcf.gz: Times:style=Regular
/usr/share/fonts/X11/75dpi/timB18-ISO8859-1.pcf.gz: Times:style=Bold
/usr/share/fonts/X11/100dpi/timBI12-ISO8859-1.pcf.gz: Times:style=Bold Italic
/usr/share/fonts/X11/100dpi/timBI08-ISO8859-1.pcf.gz: Times:style=Bold Italic
/usr/share/fonts/X11/100dpi/timBI10-ISO8859-1.pcf.gz: Times:style=Bold Italic
/usr/share/fonts/X11/100dpi/timBI14-ISO8859-1.pcf.gz: Times:style=Bold Italic
[…]

Is Helvetica a special case?

Based on a partial list I can't say why it's ok for you.
Could you try to remove those adobe fonts and see if the rendering of your pdfs is ok or not ?
That said, hacking around a built Firefox isn't really a good idea.

You can try to play with font-config. I think it's possible to have some specific mapping for some specific apps.
Another possibility is to run firefox with an env var set: FONTCONFIG_FILE which specifies the path of the font config to use.

Hmm, I think Fontconfig is actually working, but pdf.js ignoring it. (Support by the fact, that Evince is working.)

@mariux$ fc-match Helvetica
n019003l.pfb: "Nimbus Sans L" "Regular"

So, that font should be chosen. Evince uses it too.

For completeness, on my Debian Sid/unstable installation:

$ fc-match Helvetica
NimbusSans-Regular.otf: "Nimbus Sans" "Regular"

And that is used by Evince too.

On MarIuX, removing the bitmap fonts, gets Firefox/pdf.js working:

$ sudo rm -rf /usr/share/fonts/X11/75dpi/helv*
$ sudo rm -rf /usr/share/fonts/X11/100dpi/helv*
$ sudo fc-cache

We have users, still using X programs, using this Helvetica font, so removing them is not an option for us.

As this is a regression, can pdf.js commit https://github.com/mozilla/pdf.js/commit/53134c0c0bb2d19244dd8c31aa4e8e6d01a657e4 please be reverted until another solution is found?

Rémi, just to be sure, is that commit also the culprit in your case? (I am asking, because I am unable to reproduce your issue.)

Reverting this patch will imply to use "serif/sans serif" fonts when the font isn't embedded which means that it can fallback on whatever font on the OS: I'm not sure it's in general better even if it is for you.
You wrote, in your bug report, "For non-embedded fonts, a better substitute font should be tried, or the user informed.", it's exactly what the patch you want to revert tries to achieve here but you've a "bad" font and you're blaming us.
Did you try to have a specific fontconfig for Firefox ?
I just tried:

cat > /etc/fonts/conf.d/70-no-bitmaps-firefox.conf << "EOF"
<?xml version='1.0'?>
<!DOCTYPE fontconfig SYSTEM 'fonts.dtd'>
<fontconfig>
  <match>
    <test qual="all" name="prgname" target="pattern" compare="eq">
      <string>firefox</string>
    </test>

   <selectfont>
     <rejectfont>
       <pattern>
         <patelt name="scalable"><bool>false</bool></patelt>
       </pattern>
     </rejectfont>
   </selectfont>
  </match>
</fontconfig>
EOF

then fc-cache -rv, then I restarted Firefox and it wfm.
That said, technically speaking this bug is not a regression but it highlights something wrong in your setup and I understand that for you it's a regression. So as said before I'll try to figure out a solution to improve things but when I'll have some time to do it.

Did you try to have a specific fontconfig for Firefox ?
I just tried:
[…]
then fc-cache -rv, then I restarted Firefox and it wfm.

First, thank you very much for posting that Fontconfig snippet. It also worked here.

Reverting this patch will imply to use "serif/sans serif" fonts when the font isn't embedded which means that it can fallback on whatever font on the OS: I'm not sure it's in general better even if it is for you.

I am still missing a piece of the puzzle. My ignorant assumption is still, that the same font as determined by fc-match Helvetica would be used.

You wrote, in your bug report, "For non-embedded fonts, a better substitute font should be tried, or the user informed.", it's exactly what the patch you want to revert tries to achieve here but you've a "bad" font and you're blaming us.

See my reply above. fc-match does not show that font but Nimbus. How do Evince or Ocular do it? Why does pdf.js choose a different font?

That said, technically speaking this bug is not a regression but it highlights something wrong in your setup and I understand that for you it's a regression. So as said before I'll try to figure out a solution to improve things but when I'll have some time to do it.

I prefer Linux’ “no regressions rule”. ;-) As above, no idea what is wrong in the setup, if bitmap fonts are installed.

In general it's an impossible problem to solve.

  1. A user creates a pdf with its helvetica font from x11-font-adobe-100dpi but doesn't embed the font
    So if someone else open the pdf and helvetica is substituted with Nimbus then they will complain.
  2. A user creates a pdf with normal helvetica but doesn't embed it.
    So if someone else open the pdf and it's substituted with Nimbus then they'll be ok.

In the first case the user could say "fc-match 'helvetica' is returning helv** and not Nimbus, why you guys are you using Nimbus ??"
There are no heuristics to guess what the original user really wanted to do: we aren't magicians.

In looking quickly at https://gitlab.freedesktop.org/poppler/poppler/-/blob/master/poppler/GlobalParams.cc#L947, it seems that the preferred font extensions are ttf, otf, ... but not pcf, so maybe it's the reason.
The real problem is that pdf creators should embed their fonts, otherwise it can lead to some unexpected rendering.

Hi, I created an issue on the GitHub project, and was notified of this thread.
https://github.com/mozilla/pdf.js/issues/17401

I think there are two things that I'm not clear on that were possibly not addressed in this thread.

  1. Nimbus Roman was on the substitution list before DejaVu Serif but it is not selected
% fc-list "Nimbus Roman"
/home/jlw/.local/share/fonts/urw-base35-fonts/NimbusRoman-Bold.otf: Nimbus Roman:style=Bold
/home/jlw/.local/share/fonts/urw-base35-fonts/NimbusRoman-Italic.otf: Nimbus Roman:style=Italic
/home/jlw/.local/share/fonts/urw-base35-fonts/NimbusRoman-BoldItalic.otf: Nimbus Roman:style=Bold Italic
/home/jlw/.local/share/fonts/urw-base35-fonts/NimbusRoman-Regular.otf: Nimbus Roman:style=Regular
  1. My fontconfig setup aliases Times to Linux Libertine but that was not honoured.
    Is it that the fonts from that fallback list will take priority over fontconfig aliases?

Thank you for creating and supporting this project.

I have been fighting what I believe is the same problem in the Firefox 121.0 packaged in Void Linux. The fontconfig override proposed above by :calixte has resolved the issue for me also. Thank you!!

I would only like to add, that as much as I appreciate the effort expended on this, surveying the Internet one rarely find issues reported with evince, okular, and so on, "but it works fine in Firefox." Usually it goes the other way. So perhaps, simply making pdf.js "do what evince does" is not bad advice? Maybe we have made things worse by putting too many band-aids on the wound, and also hindered debugging by making Firefox disregard fontconfig selections, as commented above.

On Linux, the font substitution as defined in fontconfig should be honored thanks to:
https://github.com/mozilla/pdf.js/pull/17405
Could you check with this viewer:
https://mozilla.github.io/pdf.js/web/viewer.html
that everything is ok ? (to open a file: click on the button with chevrons on the right and then Open)

This bug should be fixed now. Please reopen if it's still a problem.

Status: UNCONFIRMED → RESOLVED
Closed: 1 year ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: