[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: script-representative-chars vs incomplete fonts
From: |
Kévin Le Gouguec |
Subject: |
Re: script-representative-chars vs incomplete fonts |
Date: |
Mon, 13 Sep 2021 00:21:30 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
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.