Permissive font pattern by default (fix broken layout)

[sergeykish]

Layout broken if font is not found with user error (createFontSet)

Pango 1.44 dropped support for FreeType in favor of HarfBuzz thus losing support for traditional BDF/PCF bitmap fonts. There would be no xorg-fonts-misc on future installations.

Fixes #348

Description

Change default fontName to accept any font. Previous default expects XOrg misc font (PCF) which is not supported in pango 1.44 anymore and would not be present in future installations.

Font not found causes silent user error (createFontSet) and breaks Layout.

Checklist

• I've read CONTRIBUTING.md

• I tested my changes with xmonad-testing

• I updated the CHANGES.md file

I've tested with latest git versions of xmonad and xmonad-contrib

[liskin]

So if future distros are going to not ship misc fixed PCF fonts, why do we expect them to ship any PCF fonts at all? Wouldn't a better fix be an #ifdef that uses something like xft:monospace when xft is enabled?

[geekosaur]

That's what I suggested in the original bug report.

…

On Mon, Jun 1, 2020, 03:48 Tomáš Janoušek ***@***.***> wrote: So if future distros are going to not ship misc fixed PCF fonts, why do we expect them to ship any PCF fonts at all? Wouldn't a better fix be an #ifdef that uses something like xft:monospace when xft is enabled? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#349 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAPRFIF7FNZOKNRHC3KLTCTRUNMMBANCNFSM4NPLDF3A> .

[sergeykish]

Sorry, I'm not qualified to answer. I do not yet understand how various font systems work. What does switch to harfbuzz mean, does it support XLFD?

There was no difference when I removed fuse_xft. It should be

I've found another fallback

I've spent a day trying to understand what is going on. Current results - X Server contains built in font (kind of) which is selected by Xmonad config. This font is not present in the system. Everything works once I install package containing font. So it should be dependency of X Server on Arch Linux.

But this font behaves strange - with xset fp /usr/share/font/TTF X Server produces much better error - both with xfontsel and xmonad:

X Error of failed request:  BadName (named color or font does not exist)
  Major opcode of failed request:  45 (X_OpenFont)
  Serial number of failed request:  10
  Current serial number in output stream:  11

And xmonad pulls this buggy font even after I've installed terminus font (does not match foundry).

I believe each project may be improved a bit. Filling issues in XOrg and Arch Linux trackers.

my test case in shell

[liskin]

Sorry, I'm not qualified to answer. I do not yet understand how various font systems work. What does switch to harfbuzz mean, does it support XLFD?

I don't think it does.

That being said, it's irrelevant, anyway. xmonad didn't switch to harfbuzz, pango did, and xmonad doesn't use pango. xmonad uses XLFD and optionally Xft. Both support bitmap fonts and that support isn't going away. So the only relevant question is still this: are current/future distros shipping bitmap fonts or not? If not, then defaulting to an XLFD font descriptor, no matter how permissive (wildcard-y), doesn't make sense, as going through XLFD means no antialiasing, and antialiasing is necessary for vector fonts.

If not depending on the core X11 fonts is a packaging bug in Arch that's been fixed since, I think we can close this bug. If, on the other hand, modern systems only install TTF fonts, then we need to default to something like xft:monospace as -*-*-*-*-*-*-*-*-*-*-*-*-*-* will either result in ugly rendering or fail to select any fonts at all (xlsfonts on my system doesn't list any TTF fonts at all).

[slotThe]

If not depending on the core X11 fonts is a packaging bug in Arch that's been fixed since, I think we can close this bug. If, on the other hand, modern systems only install TTF fonts, then we need to default to something like xft:monospace as -*-*-*-*-*-*-*-*-*-*-*-*-*-* will either result in ugly rendering or fail to select any fonts at all (xlsfonts on my system doesn't list any TTF fonts at all).

We have had a few people on arch reporting that the prompt doesn't come up. This seems to always invariably be a font issue (the default font for the prompt is also set to -misc-fixed-*-*-*-*-12-*-*-*-*-*-*-*). It seems like a pretty safe bet that bitmap font support will wane in other distros as well sooner or later. I would be in favour of switching every occurance of this kind of default font to something like xft:monospace

[geekosaur]

You'll want to make sure the use_xft flag defaults to enabled.

[slotThe]

Good point.

@sergeykish are you still interested in this? The xft:monospace solution seems to be the most future proof at this point; you'd also need to fix this in all other modules that use some form of default font (like XMonad.Prompt)

[geekosaur]

I would actually recommend that the Cabal flag define a CPP macro that can be used to select an appropriate font expression depending on whether use_xft is enabled or not.

I would also beware of the all-* XLFD spec, because X11 will use the first font it happens to find in its enumeration which may well be unreadable. A more appropriate default would be something like -*-*-medium-r-normal-*-*-*-*-*-*-*-iso8859-* which is imperfect (it may select a very small or very large font) but better than e.g. dingbats or the CJK-encoded font I got with all-* in local xfontsel. (Sadly, there's no way to say the second last field should be either iso8859 or iso10646.)

Even better would be a way to do multiple fallbacks, but that again requires use_xft and I'm not sure how well the fallback syntax works when mixing XLFD and XFT fonts. And requires other support in the code IIRC, and only some contribs support it.

[slotThe]

@liskin @geekosaur I pushed a few changes; what do you people think? This is something I'd like to get done before 0.17

[geekosaur]

Looks good to me.

[liskin]

@slotThe Why are we changing the XLFD default, and why to -*-*-medium-r-normal-*-*-*-*-*-*-*-iso8859-* in particular? Especially the iso8859 bit seems a bit weird these days. :-)

[geekosaur]

See the earlier discussion. 10646 would also work, the real question is which set might be installed.

[slotThe]

On Fri, Mar 19 2021 14:36, Tomáš Janoušek wrote: @slotThe Why are we changing the XLFD default, and why to `-*-*-medium-r-normal-*-*-*-*-*-*-*-iso8859-*` in particular? Especially the iso8859 bit seems a bit weird these days. :-)

As geekosaur already said, I just went with what was said above. I don't really have a strong opinion on this, and I don't suspect it matters very much, because we compile with XFT support by default and hence I don't think these fonts will see much use anyways.

[liskin]

As geekosaur already said, I just went with what was said above. I don't really have a strong opinion on this, and I don't suspect it matters very much, because we compile with XFT support by default and hence I don't think these fonts will see much use anyways.

Well, it'd break my setup if I hadn't enlarged the fonts last week, so I wouldn't be that sure about it not mattering. :-)

The thing is, @geekosaur's message doesn't really explain the change. It explains why -*-*-medium-r-normal-*-*-*-*-*-*-*-iso8859-* is better than -*-…-*-, which I'm in no way trying to dispute, but it doesn't explain why any change to the XLFD default is necessary. To answer that question, we'd need to know if there are distros that don't ship misc fixed fonts but still ship other useful bitmap fonts addressable using XLFD, and I believe/hope the answer to that is no, so as long as we default to xft when available, the sensible -misc-fixed-… XLFD default can stay and we gain absolutely nothing by changing it to something that allows more fonts in weird rare broken setups but selects wrong fonts in the traditional common non-broken setups.

[geekosaur]

I only came into it after the change to -*-(...)-* had been made, so I can't speak to that one. I would suspect however that there willl be two groups: those that move completely to XFT, and those who keep the older setup including the (formerly?) required -misc-fixed font.

[slotThe]

I would suspect however that there willl be two groups: those that move completely to XFT, and those who keep the older setup including the (formerly?) required -misc-fixed font.

That is a fair point. I reverted back to misc-fixed-style fonts for the non-XFT users and just changed the XFT fonts.

[liskin]

Perfect.

(We use #ifdef in the rest of the codebase, but I'm not sure if that's worth following or whether #if is fine. Feel free to merge if you know what you're doing. :-))

[slotThe]

Ah, you're right of course. In this case it doesn't really matter because if XFT is defined then it's also 1 and so #if and #ifdef do the same, but I think it's worth following what we do elsewhere.