bug#52888: 29.0.50; font_{delete_unmatched,score} do not handle nil FONT_WEIGHT_INDEX

[Eli Zaretskii]

> From: Sean Whitton <spwhitton@spwhitton.name>
> Date: Fri, 31 Dec 2021 19:35:53 -0700
> 
> >   if (FcPatternGetInteger (p, FC_WEIGHT, 0, &numeric) == FcResultMatch)
> >     {
> >       FONT_SET_STYLE (entity, FONT_WEIGHT_INDEX, make_fixnum (numeric));
> >     }
> 
> ... or FcPatternGetInteger returns something other than FcResultMatch,
> which is in fact what is happening.
> 
> I tried FcPatternGetDouble in an else branch and that fails too, so it
> seems fontconfig cannot determine a weight for the variant in question.
> 
> So, perhaps each of the if (FcPatternGetInteger (...)) conditionals that
> corresponds to one of the FONT_* fields that the font.c functions assume
> are fixnums should have an else branch to return Qnil?

Maybe.

However, the question that I think we should ask ourselves at this
point is whether there's a reasonable way to process these fonts into
a font spec that Emacs expects.  So if FcPatternGetInteger and
FcPatternGetDouble don't do the job, perhaps there's another
fontconfig function that does, or maybe these fonts need to be
processed in some slightly different ways (like in a loop, for
example) to produce the weight matches from them?  Can you perhaps ask
the developers of this font to help?  Or maybe we could ask on the
fontconfig forum?

If it turns out that there's no way we could adapt our code to these
fonts (which I'd find hard to believe), we should then look for a way
of detecting them so that we could reject them on the font backend
level, before they get into the platform-independent code in font.c,
e.g. with the 'else' branch that you suggest.  However, I suspect that
the fact we don't have such branches is not just because we blindly
assume that can "never happen", so maybe doing so would break
something.

In any case, trying to accept those fonts instead of rejecting them
would be a better solution, if we can reasonably code it.

Thanks.