https://bugzilla.redhat.com/show_bug.cgi?id=2262410
--- Comment #32 from Akira TAGOH tagoh@redhat.com --- (In reply to Oleg Oshmyan from comment #31)
No, I mean fonts that are designed to support a single language. A font _can_ provide good support for everything at once via GSUB, but such global support isn't all that common and more often you find that you have e.g. a Japanese font, a mainland Chinese font and a Hong Kong Chinese font with near-identical glyph coverage but different shapes. My impression has been that this is (at least part of) why fonts.conf allows specifying what languages a font should be preferred for.
Well, because Unicode unified similar shapes. we can't guess a language from a character coverage completely, particularly if it is all-in-one font.
Indeed, Noto Sans itself is a counterexample. I don't understand why it isn't all a single font, but it isn't: instead, we have a myriad of language-specific fonts with distinct names.
It isn't that simple. Such all-in-one font has another problem. As you can see in the file picker in plasma, character width and height may be too wider/taller because it will be aligned to the most widest/tallest one for fixed font and monospace, or just for better looking. also, they won't be recognized as monospace because they have too many size of glyphs.
However, given that X is key codepoint to represent lang L, it can be simplified because:
a. font A is missing a glyph X so it doesn't satisfy lang L. b. font B has full overage for M so it satisfies lang L. c. font B will be picked up if requesting lang L.
This might be useful when a lang L is requested, but again, the case here doesn't request any particular language at all. All we know is that we need "the `sans-serif` font".
Yes, that's right. so what's wrong so far? fontconfig returns all sans-serif fonts *as* requested. there are nothing wrong there. other tasks are up to libass.
We could explicitly fetch the current system locale
in libass and ask Fontconfig to look for this language, but I guess we kinda expected that Fontconfig already does this for substitutions/aliases on its own.
No, as I noted, current usage of the results from FcConfigSubstitute() is completely wrong. otherwise fontconfig doesn't need to provide APIs such as FcFontMatch/FcFontSort at all.