On Tue, Aug 30, 2022 at 10:47:46PM +0200, Storkman wrote:
> but more generally,
> the "set of fonts covering as wide variety of code-points as possible"
> ...is just the set of all installed fonts, isn't it?
Not entirely. Let's say a system has 3 fonts installed: A, B and C. A
and B both *only* cover English characters and C covers Chinese ones.
In that case, our list would be [A, C]. B can be eliminated from the
fallback-list since it doesn't add anything new. (Or it could be [B, C]
with A eliminated).
We could of course add a reasonable upper-limit to this list, say
128/196 or something along those lines.
And just so everyone is on the same page: drw ALREADY maintains such a
list. I'm only proposing we change *how* we construct the list (assuming
it's possible).
This is roughly how things currently work:
0. at startup push the user specified fonts (in config.h) to the list
// list = [ userfont0, userfont1 ]
foreach code-point:
1. walk the list to find a font that can render the code-point.
if any of the fonts in the list can render it, just use that.
2. if not, then run XftFontMatch() to see if we can find
a match.
3. If XftFontMatch() finds a match then append the
matched font to the list (so that step 1 can find it
next time around).
// list = [ userfont0, userfont1, matchedfont0, matchedfont1
... ]
My idea is to simply remove step 2 and 3 from the loop and construct the
list at startup so we don't have to constantly keep calling
XftFontMatch() inside the loop for each unknown code-point.
> I'm a big fan of pre-calculating this list before compiling the program.
I was talking about doing it on program startup since I don't think you
should have to recompile the program every time you install a new font
for font fallback to work.
> If your question is simply "which code-points ARE NOT supported by ANY font",
Wasn't exactly what I was looking for but even this *could be* an
improvement over the current system if it can be done in reasonable
space, speed and code-size.
- NRK
