On Sun, Oct 01, 2017 at 06:09:00PM -0400, Gary Allen Vollink wrote:
> Patch partially addresses this question from last month:
> https://lists.suckless.org/dev/1708/32111.html
>
> If a Glyph simply does not exist within the fonts of a system,
> fontconfig ends up returning the original default font again. At this
> point, 'st' happily opens it again, and holds a new frc array slot
> hostage with a duplicate opened font in the array. Same glyph, it
> won't happen again, but for a different glyph that doesn't exist,
> things get really crazy with opens and closes (especially once the
> hard-coded 16 fallback cache limit is reached). Under a certain mix
> of legitimate fonts on the screen, it's possible to close a font that
> is actually being used (This never works out well).
>
This sounds like a fontconfig bug or not? Which version of fontconfig do
you use?
> I attached a fairly simple diff that stops this.
>
> Check-in comment:
> If fontconfig returns a font that has no matching glyph, close the now
> opened, unused font.
>
> I first started to investigate a problem under macOS that happens
> because macOS actually has a fallback font. There, once any single
> Glyph cannot be found at all, no other Glyph that had not already been
> loaded will ever be looked up. This, because the loaded fallback font
> will ALWAYS return a positive Glyph. In addition to the fix attached,
> the fix for this under macOS seems to be in .fonts.conf, so I won't
> bother with further details. (Feel free to reach out off-list if you
> want more info).
>
> Thank you,
> Gary Allen
> --- a/x.c 2017-09-30 15:46:51.713848500 -0400
> +++ b/x.c 2017-10-01 16:59:13.786729400 -0400
> @@ -1100,8 +1100,13 @@
>
> glyphidx = XftCharIndex(xw.dpy, frc[frclen].font, rune);
>
> - f = frclen;
> - frclen++;
> + if (!glyphidx) {
> + XftFontClose(xw.dpy, frc[frclen].font);
> + frc[frclen].unicodep = 0;
> + } else {
> + f = frclen;
> + frclen++;
> + }
>
> FcPatternDestroy(fcpattern);
> FcCharSetDestroy(fccharset);
--
Kind regards,
Hiltjo
