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

[Sean Whitton <spwhitton@spwhitton.name>]

Hello,

On Sat 01 Jan 2022 at 09:15am +02, Eli Zaretskii wrote:

>> 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?

I've filed a bug[1] and posted to the fontconfig mailing list.

To be clear, we are generating valid font specs for a number of weights
available in this multi-weight .ttf.  It's just that some of the
variants that are in there do not seem to have a valid weight, or
something like that.  So if we give up on those variants, we wouldn't be
giving up on the whole .ttf, so it's not a complete loss.

[1]  https://github.com/googlefonts/Inconsolata/issues/69

-- 
Sean Whitton