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