Courier font is not rendering correctly on Linux

[deron-dev]

Bug Report

Behavior

This image/vector graphic seems to render incorrectly.

Mullvad:

Brave:

Firefox:

Version & System Info

OS: Fedora Linux 37 (Xfce) x86_64 
Host: Strix 17 GL703GE 1.0 
Kernel: 6.3.8-100.fc37.x86_64 
DE: Xfce 4.16 
WM: Xfwm4 

---

Thanks much to MV & Tor devs for an awesome project :)

[Thorin-Oakenpants]

FWIW, renders fine on Windows in TB, TB-alpha, TB v13 test build, MB, FF ...

@terminal-root What do you get in Tor Browser?

[ruihildt]

I can reproduce the issue in MB 12.0.7 and TB 12.5 on Fedora 38/KDE.

[PieroV]

Hello @terminal-root. That SVG file uses Courier, which isn't a standard font. It should use Courier,monospace, instead. That said, for some other problems we had a while ago, I'd love to make MB for Linux alias Arial, Courier and Times New Roman with Arimo, Cousine and Tinos (see https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41799).

[Thorin-Oakenpants]

I'd love to make MB for Linux alias Arial, Courier and Times New Roman

I'd rather not go down this slippery slope

That SVG file uses Courier,

So this SVG file also breaks in FF then (assuming the user doesn't have courier). Someone should confirm that. Or inspect a div set as courier and look at the font inspector

We shouldn't be in the business of unbreaking bad website design. The default font (for en-US) is serif and this is why it doesn't line up. So this is not TB/MB's fault. The issue title is misleading now - most/all/some linux distro's do not ship with courier

[ruihildt]

Technically you're correct.

Though I feel this is a much a technical decision as it is a user experience decision. It seems it's a common method for various Linux OS to substitute those proprietary fonts with matching free alternatives.

The difference in font rendering between OS is an issue, and here the user expects it to work, as it works in Firefox on the same OS.

[PieroV]

I'd love to make MB for Linux alias Arial, Courier and Times New Roman

I'd rather not go down this slippery slope

Could you please elaborate more? Users will have them rendered with Arimo, Cousine and Tinos.

That SVG file uses Courier,

So this SVG file also breaks in FF then (assuming the user doesn't have courier). Someone should confirm that. Or inspect a div set as courier and look at the font inspector

We shouldn't be in the business of unbreaking bad website design. The default font (for en-US) is serif and this is why it doesn't line up. So this is not TB/MB's fault. The issue title is misleading now - most/all/some linux distro's do not ship with courier

On Firefox (no RFP) it works. I don't have a Courier/Courier New font on my OS, and yet Firefox manages to match it with a serif monospace font (Inkscape would associate with my default monospace, with is a sans-serif monospace).

The inspector shows this:

Courier:familylang=en:style=Regular:stylelang=en:fullname=Courier Regular:fullnamelang=en:slant=0:weight=80:width=100:spacing=100:foundry=ibm:file=/usr/share/fonts/type1/texlive-fonts-recommended/pcrr8a.pfb:index=0:outline=True:scalable=True:charset=20-7e a0-10f 112-113 116-122 124-12b 12e-148 14a-14d 150-173 178-17e 192 1f5 2c6-2c7 2c9 2d8-2dd 393 398 3a3 3a6 3a9 3b1 3b4-3b5 3bc 3c0 3c3-3c4 3c6 2013-2014 2017-201a 201c-201e 2020-2022 2026 2030 2039-203a 203c 203e 2044 2070 2074-207a 207d-207f 2122 2126 215b-215e 2190-2194 21b5 2212 2215 2219-221a 221e-221f 2229 223c 2248 2260-2261 2264-2265 2500 2502 250c 2510 2514 2518 251c 2524 252c 2534 253c 2550-256c 25a0 2640 2642 2660 2663 2665-2666 266a-266b f6e2 f6e8 fb00-fb04:lang=aa|ay|bi|br|ca|ch|co|cs|da|de|en|eo|es|et|eu|fi|fj|fo|fr|fur|fy|gd|gl|gv|ho|hu|ia|id|ie|io|is|it|ki|kl|lb|lt|mg|mh|mt|nb|nds|nl|nn|no|nr|nso|oc|om|pl|pt|rm|sk|sma|smj|so|sq|ss|st|sv|sw|tk|tl|tn|tr|ts|uz|vo|vot|wa|wen|wo|xh|yap|zu|an|crh|csb|fil|hsb|ht|jv|kj|ku-tr|kwm|lg|li|ms|na|ng|pap-an|pap-aw|rn|rw|sc|sg|sn|su|za:fontversion=0:fontformat=Type 1:decorative=False:postscriptname=Courier:color=False:symbol=False:variable=False:fonthashint=False:order=0

Oh, well:

fc-match Courier
pcrr8a.pfb: "Courier" "Regular"

fc-match 'Courier New'
LiberationMono-Regular.ttf: "Liberation Mono" "Regular"

The former is the file that Firefox reference, but I can see clues like TeXLive (the TeX distribution you usually have on Linux) and PostScript. And PFB stands for Printer Font Binary, that are fonts in the PostScript format.

Now that I think of it, Courier is indeed a standard PostScript font, with Helvetica, Times etc. But I'm not sure about the importance we should give to that, since PostScript Level 3 has far too many fonts (136), and it isn't a web standard, it's a printing standard.

TL; DR: Firefox (no RFP) works as expected, but my system isn't a normal system. We'd need to test on a more normal one.

Edit: on my Ubuntu Mate VM, I get it rendered with Nimbus Mono PS (again, PostScript).

[ruihildt]

I have tested on mine (Fedora/KDE) and I don't have Courier installed, so it's also substituted somehow.

[PieroV]

I have tested on mine (Fedora/KDE) and I don't have Courier installed, so it's also substituted somehow.

Nimbus Mono PS also on Fedora (just tested with Fedora 37 KDE live on a VM). Not sure 37 is still the latest, in case could you check the fonts tab on the inspector? It's hidden in the arrow menu.

Also, I've checked. Courier and Courier New don't have the same metrics, so me talking about Courier New is slightly misleading. However, I haven't tested MB without fonts.conf.

[Thorin-Oakenpants]

FYI: it is broken on FF on android (i.e it is not monospaced). Mac ships with and we whitelist courier.

Could you please elaborate more? Users will have them rendered with Arimo, Cousine and Tinos.

So after percolating in my head as I watched a movie

• you alias the three fonts (why all three/ surely the only relevant one is monospace for cases like this - alignment)
• this needs testing
  • do we then need to whitelist the fonts for the alias mapping to take place? IDK? Maybe not since they were still detcted in out earlier tests (because the sizes changed) - this explains that the missing font.config fell back to the linux system one, the one which mapped them already?
  • if the fonts used are then the same (arimo etc) then there should be no (extra) entropy, but the fonts would be detected as present (which is fine)

This is all terribly exciting, I must say. Such entropy to be gained in the fallback for courier et al, since almost every distro seems to differ on what to use and do. Great Scott!

[Thorin-Oakenpants]

Hmm .. so does FF without RFP on linux detect courier when courier is not installed. If you use TZP and look at the sizes, you might fine e.g. Courier and Liberation Mono both detected with the same sizes

[Thorin-Oakenpants]

if you want to modify the fntData object via console, go ahead - add add more fonts to fntData.full - for linux this already contains courier and liberation mono

[PieroV]

• if the fonts used are then the same (arimo etc) then there should be no (extra) entropy, but the fonts would be detected as present (which is fine)

Yes, IIRC it never fell back to system fonts. From what I remember Firefox did this trick: «Uhm, Courier New you say? I sure know it, it's Cousine. Oh wait, Cousine it's allowed! Let's just render it!!».

But as you've seen, my system thinks "Courier New" is "Liberation Mono". But also:

fc-match Cousine
LiberationMono-Regular.ttf: "Liberation Mono" "Regular"

I wonder if somehow it did the opposite when Liberation Mono is not present but Cousine is. I need some sandboxing to test this (but maybe I need food first :grin: ).

[Thorin-Oakenpants]

Right, that's what I though. Windows does something maybe similar ... MS Shell Dlg \32 you say .. wait, that's Tahoma (usually AFAICT, MS docs is very vague) - but since this is a system alias (like the linux alises), it just works. Weirdly though, even if not whitelisted, it is still detected, edit and actually used in content (might have something to do with how windows uses widgets?)

In terms of our fallback, it's not really going to work either, because the font config is missing so our fallback is missing - and the system one takes over (if it has one) = so it's still broken

[ruihildt]

Not sure 37 is still the latest, in case could you check the fonts tab on the inspector?

It's DejaVu Sans Mono. I'm on Fedora 38/KDE. (Gnome, the default Fedora interface potentially has different font choice?)

[PieroV]

Not sure 37 is still the latest, in case could you check the fonts tab on the inspector?

It's DejaVu Sans Mono. I'm on Fedora 38/KDE. (Gnome, the default Fedora interface potentially has different font choice?)

I was on KDE, too (I have a Fedora KDE iso for when people tell me they have a problem with KDE or with Fedora). Maybe the difference is between a live system and an installed system.

That makes the situation even worse.

[Thorin-Oakenpants]

That makes the situation even worse

Not in our current setup. If we alias the fonts (and do not whitelist, not sure if this matters that much as long as it works) then we also are not affected (tests pending). And if the font config is not loaded, then there isn't much more we can do - enumeration wise should still be the same, but the measurements may differ. But at least we're still not leaking all the other system fonts (and TZP adds the three fonts to expected). The missing font config exposes other entropy anyway - e.g. ant-aliasing? So the font whitelist is workable as a fallback, but we would want something more robust to detect a broken font config path

[PieroV]

We'll very likely resolve this with 14.0. I opened https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41237 and sent https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/merge_requests/1036.

[Thorin-Oakenpants]

Okie dokie .. update time

• https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41799#note_3076817

So this can be marked ~~at~~ as a 14.0 release improvement

[Thorin-Oakenpants]

godamnit .. ninja'd by @PieroV .. what is the world coming to