Re: [dev] Potential bug in st fallback font code

From: Eric Pruitt <eric.pruitt_AT_gmail.com>
Date: Sat, 21 Feb 2015 07:32:54 -0800

On Sat, Feb 21, 2015 at 03:00:05PM +0100, FRIGN wrote:
> I must admit that I personally am not happy with the font-cache in st.
> For each character drawn, it is checked if it is in the current fontset.
> If not, some fontconfig-magic happens in the background, selecting a
> font which contains the character.
> A few months ago I spent an evening rewriting the fontconfig-backend so
> that you would specify _two_ fonts in the config.h (font[] and fontfb
> []). Usually, in a terminal emulator, you need your font for daily
> usage and one "default" font which has all the Unicode characters.
> I understand fontconfig's approach to take every font in scope of the
> system in regard, but for a terminal emulator, this is too complex and

I don't like that solution simply because a lot of a Asian languages
only have comprehensive character coverage through a combination of
multiple fonts, and having a single fallback would not cut it for me.

In my dwm patch, I worked around this problem by creating a proper font
structure from the fallback search result and then calling XftCharExists
on the codepoint to actually verify that the fallback font contains the
character I want. Something else I've considered that is probably more
performant is calling 'FcCharSetAddChar(fccharset, " ");' to determine
what the user's default font is (I'm assuming that the vast majority of
default fonts contains a space) then using strstr or strcmp to make
certain the fallback font isn't the default font.

> Dropping the fontconfig-magic and only falling back if a Rune is not in
> the current font dropped a lot of code in my case.
> In config.def.h, the fallback font fontfb[] could already be set to some
> sane default font everybody has and which has a big range of
> Unicode-characters.

Having configurable fallbacks is a good idea IMO, but again, I don't
think specifying _one_ fallback is sufficient. Instead of specifying a
single fallback font, I would suggest making the font configuration
variable an array that is used to prepopulate the font cache. This still
allows for generic fallback support while allowing each user to optimize
the font configuration for speed and aesthetic preferences on a
particular system.

Eric
Received on Sat Feb 21 2015 - 16:32:54 CET