Re: script-representative-chars vs incomplete fonts

["Kévin Le Gouguec" <kevin.legouguec@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

> I think it is easier to request both upper-case and lower-case
> letters; since the lower-case letters are at fixed offsets from their
> upper-case variants, we can compute the codepoints without changing
> the original database.

Noted.

>> Not sure it makes sense as-is though, since it yields a vector; judging
>> by script-representative-chars's docstring (and a cursory glance at
>> ftfont_list and font_match_p), a list would be more appropriate, to make
>> all codepoints mandatory?
>
> Why do you say that a list would be more appropriate?  The doc string
> of script-representative-chars says:
>
>    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.

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?
Hence it would indeed not matter whether we used a vector or a list for
the purposes of querying fontconfig.

(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)

Again, thanks for your advice.