Re: [dev] [tabbed] utf8 characters not displayed in tabs

From: NRK <nrk_AT_disroot.org>
Date: Tue, 30 Aug 2022 22:23:44 +0600

On Tue, Aug 30, 2022 at 05:36:31PM +0200, Hiltjo Posthuma wrote:
> "
> The font fallback in dwm and dmenu is handled via libsl (i.e drw.c) and
> it's a huge mess [0].
>
> The way it works is also very inefficient (it calls XftFontMatch() for
> every single "unknown" code-point). The `nomatches` cache is merely
> there to stop the bleeding and is not really a proper fix.
> "
>
> This part specificly. The tone if very whiny.

I see; the intention there was to just describe/explain why I think
replicating drw is not a good idea. It wasn't meant to be whiny.

> It doesn't help complaining the code is a mess or improper without
> proposing a patch.

The "proper" way (IMO) would be to build up a list of fonts which would
be capable of representing as many code-points available in the system
*right at startup* - instead of checking each unknown code-point as we
go.

This way if the code-point cannot be found within the list; we'll know
right away that it's a missing glyph and there won't be any need to call
XftFontMatch for each "unknown" code-point.

The problem is, as I said, I'm not sure if it's even possible/feasible
with Xft/FontConfig as I'm not very familiar with those libraries. If
someone knows the answer, then feel free to speak up.

If it is possible and someone can point out which routines I should be
looking at then I can try to take a crack at it. In case that's not
possible, then there's probably not a whole lot that can be done about
the situation.

- NRK
Received on Tue Aug 30 2022 - 18:23:44 CEST

This archive was generated by hypermail 2.3.0 : Tue Aug 30 2022 - 18:36:08 CEST