Re: script-representative-chars vs incomplete fonts

[Eli Zaretskii <eliz@gnu.org>]

> From: Kévin Le Gouguec <kevin.legouguec@gmail.com>
> Cc: help-gnu-emacs@gnu.org
> Date: Mon, 13 Sep 2021 00:21:30 +0200
> 
> >    CHARS is a list or a vector of characters.
> >
> > So both lists and vectors are possible and supported.
> 
> The docstring also says this:
> 
>     If it is a list, all characters in the list are necessary for
>     supporting SCRIPT.
>     If it is a vector, one of the characters in the vector is necessary.

So you want to require both upper- and lower-case variants?

> That led me to think that we'd want a list, but now that I've looked at
> ftfont.c and font.c more closely, I get the impression that this
> distinction only applies to the verification step in font_match_p?

Basically, yes.

> Hence it would indeed not matter whether we used a vector or a list for
> the purposes of querying fontconfig.

No, but if we require both upper- and lower-case variants, we will
reject fonts such as KpMath.

> (I hope I'm not misreading the code; apologies if so.  I'm still not
> entirely sure I understand why ftfont_spec_pattern seems to only handle
> the list case while ftfont_list only handles the vector case, but I'm
> sure I'll figure it out eventually after some more scowling)

ftfont_list calls ftfont_spec_pattern, so both variants are handled.
My reading of that code is that ftfont.c uses
script-representative-chars as fallback for the cases when the fontset
doesn't specify a script or a charset for a font.  ftfont.c then
creates a fake "charset" on the fly out of the representative
characters.