[Top][All Lists]

[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 <> 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.


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]