Some variable fonts supports multiple weights and fontconfig returns a weight property in Range as the base pattern which is a sort of the virtual entry and has "true" in variable property. If you want to traverse all the fonts patterns and do something in the own way, you have to use FcPatternGetRange in such case. otherwise fontconfig returns a proper pattern according to the request (with FcFontMatch).
Hope that helps,
2022年1月3日(月) 11:04 Sean Whitton <spwhitton@xxxxxxxxxxxxxx>:
[re-send; looks like the list silently drops mail from non-subscribers]
Emacs is crashing when Inconsolata-VariableFont_wdth,wght.ttf is
installed and I'm trying to understand why. This is what I know. We
call FcFontList to obtain an FcFontSet, and then for each FcPattern in
that list we produce a Lisp vector containing the attributes of the
font, and that goes into the Emacs-specific font selection code. In
particular, in order to populate the weight field in that vector, we
call FcPatternGetInteger on the pattern, passing FC_WEIGHT as the second
argument. For most fonts this yields an integer representing the
When Inconsolata-VariableFont_wdth,wght.ttf is installed, the FcFontSet
contains multiple FcPatterns corresponding to entries in that file. For
most of these, FcPatternGetInteger with FC_WEIGHT yields an integer.
But for some of them, it does not; FcPatternGetInteger (and
FcPatternGetDouble) do not return the success value FcResultMatch.
Emacs's font code assumes that there is a weight associated to every
font, and so there is a crash.
One option to fix this is just to skip over entries in the FcFontSet for
which FcPatternGetInteger is unable to return a weight. But is that the
correct thing to do? I don't really understand these multi-weight .ttf
files -- what might it mean if entries in them do not seem to have a
weight at all?