[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: script-representative-chars vs incomplete fonts

From: Eli Zaretskii
Subject: Re: script-representative-chars vs incomplete fonts
Date: Mon, 13 Sep 2021 20:09:36 +0300

> From: Kévin Le Gouguec <>
> Cc:
> 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

reply via email to

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