A mystery with Fedora 36, fontconfig, and xterm (and urxvt)

June 23, 2022

As of Fedora 36, Fedora changed their default fonts from DejaVu to Noto. This changes what the standard names 'serif', 'sans', and especially 'monospace'. When I upgraded my desktops to Fedora 36, I had a very bad reaction to the 'monospace' change, because the result looks really bad. It turns out that part of the reason that the result looks bad (although not all of it) is specific to xterm, and that is where the mystery comes in.

Here is what gnome-terminal looks like displaying 'Monospace 12' on Fedora 36 (in a 50x10 window):

Gnome-terminal on Fedora 36

Here is what xterm looks like displaying the same 'Monospace 12' on Fedora 36:

Xterm on Fedora 36 with stretched out text

Xterm and gnome-terminal are about the same vertical height (and in both, Fedora 36 Noto based monospace takes up more vertical room than DejaVu monospace does), but xterm is significantly stretched horizontally because there's the text has been rendered with a lot of space between each letter. With dramatic spacing between letters in the same word, the text is less dense and harder to read and the result is fairly unpleasant to me.

The fc-match program claims that 'monospace' on Fedora 36 is Noto Sans Mono in Regular:

; fc-match monospace
NotoSansMono-VF.ttf: "Noto Sans Mono" "Regular"

I wasn't able to get very far with figuring out just what font and font options xterm is using, despite using the usual magic tricks. But I did today think to test with urxvt (and alacritty), and now I have a second puzzle because urxvt (and alacritty) render text with more spacing between letters than gnome-terminal but less than with xterm. Since I can, here is an image of it:

Urxvt on Fedora 36

The letter spacing in urxvt isn't what it should be (that would be how gnome-terminal renders it), but it's significantly less spread out and more readable than xterm renders things.

This difference in rendering between gnome-terminal, urxvt, and xterm is new with the Fedora 36 setup and Noto Sans Mono. In Fedora 35, with 'monospace' as DejaVu Sans Mono, all three had text that looked the same and came out the same size.

One of the anomalies here is that while a Fedora 36 gnome-terminal will allow you to select a custom font of 'Monospace' or 'DejaVu Sans Mono' (if you have the DejaVu fonts installed), it won't let you select 'Noto Sans Mono'. The only Noto font that appears in gnome-terminal's Preferences is Noto Emoji. It's possible that this is because Noto Sans Mono does not appear to have the 'spacing=mono' property, which causes it to not show up in eg 'fc-list :scalable=true:spacing=mono: family'.

As documented in fonts.conf if you read carefully, the 'mono' value for spacing is 100. Dumping font information in various ways (including using fc-scan on the font files), the Noto Sans Mono fonts do appear to lack a 'spacing' attribute, which probably means that they're being taken as proportional fonts. In fact this seems to be a known issue that's been outstanding since 2018, and it may not even be correct to assert that Noto Sans Mono is a genuine monospaced font, because it seems to contain some glyphs that are extra width.

Since modern fonts (in X11 and otherwise) are a mess, it's possible that I need to blame FreeType here instead of Fontconfig. Perhaps Fontconfig is always picking the same font but FreeType is being passed (or not passed) various rendering parameters that make it behave differently.

The whole thing is a mess. It feels like something went off the rails in the switch from DejaVu to Noto, but in some weird and subtle way.

(Trying to troubleshoot Fontconfig and perhaps FreeType issues is also a mess. For example, it seems inordinately difficult or impossible to get Fontconfig to tell me just what the program asked for and what Fontconfig gave it. Possibly I'm missing a magic decoder ring in all of this.)

PS: All three pictures here are from a stock Fedora 35 install that was upgraded to Fedora 36, running Cinnamon, in a virtual machine. My desktop environment has its own oddities, which is part of why I reproduced it in a virtual machine.

Sidebar: How to revert this for monospace and other fonts

Go to /etc/fonts/conf.d and copy the relevant dejavu related fonts to have a lower number, eg:

# cp 57-dejavu-sans-mono-fonts.conf 49-cks-dejavu-sans-mono-fonts.conf

The more I look at these Noto fonts, the less I like them even for the serif and sans families. I'm increasingly thinking of doing this for all three general font names, because my life is too short to squint at bad looking fonts. In fact I just did that on my home desktop and I think I'm happier with the result. Some things are perhaps too dense now, but the result feels more readable in all sorts of programs.

(I'm sure that the fine people in Fedora don't think that the Noto fonts look bad. But that's the result I get.)


Comments on this page:

By John Morton at 2022-06-24 01:17:30:

The spacing between glyphs is known as 'kerning' to font people, though that term is usually specific to proportional fonts. Might be worth hunting for that term in configuration, nevertheless.

By nobrowser at 2022-06-24 12:19:49:

There's another package involved in this mess, harfbuzz. Some parts of the processing, and I don't remember which ones, are gradually moved from freetype to harfbuzz. A possible reason for different rendering is that a program links with harfbuzz while another one doesn't, yet.

I also don't think this is specific to Fedora and Noto. I have a very similar phenomenon happening on Devuan with Terminus font. (I think it is the OTB version, but I'm cannot check that ATM.) Again the spacing in xterm is distinct from other programs.

Written on 23 June 2022.
« Signing email with DKIM is becoming increasing mandatory in practice
Even for us, SSD write volume limits can matter »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Thu Jun 23 23:36:04 2022
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.