Re: script-representative-chars vs incomplete fonts

[Eli Zaretskii <eliz@gnu.org>]

> From: Kévin Le Gouguec <kevin.legouguec@gmail.com>
> Cc: help-gnu-emacs@gnu.org
> Date: Sun, 12 Sep 2021 19:08:35 +0200
> 
> > It's not Emacs that stumbles on that font, it's your font backend
> > (probably fontconfig?).  Emacs just verifies that the candidate fonts
> > returned by the backend satisfy the requirements, and uses the first
> > font that does.  So this might mean a bug report for fontconfig and/or
> > the font designers is in order.
> 
> Right; "as luck would have it", fontconfig returns KpMath rather than
> DejaVu Math TeX Gyre; that's because Emacs only asks for U+1D49C, if I'm
> reading ftfont.c's use of Vscript_representative_chars correctly?

Emacs asks for some characters, but fontconfig should be smart enough
to return only fonts that support the Unicode block(s) of those
characters well enough.

> > What would be the purpose of breaking that range?
> > script-representative-chars can specify multiple characters per
> > script, see its doc string.
> 
> Right now script-representative-chars contains this:
> 
> > (mathematical-script 119964)
> 
> With this patch:
> 
> diff --git a/lisp/international/fontset.el b/lisp/international/fontset.el
> index 3deaff9677..461c8f830a 100644
> --- a/lisp/international/fontset.el
> +++ b/lisp/international/fontset.el
> @@ -772,7 +772,8 @@ setup-default-fontset
>    (dolist (math-subgroup '((#x1D400 #x1D433 mathematical-bold)
>  			   (#x1D434 #x1D467 mathematical-italic)
>  			   (#x1D468 #x1D49B mathematical-bold-italic)
> -			   (#x1D49C #x1D4CF mathematical-script)
> +			   (#x1D49C #x1D4B5 mathematical-script)
> +			   (#x1D4B6 #x1D4CF mathematical-script)
>  			   (#x1D4D0 #x1D503 mathematical-bold-script)
>  			   (#x1D504 #x1D537 mathematical-fraktur)
>  			   (#x1D538 #x1D56B mathematical-double-struck)
> 
> script-representative-chars would contain:
> 
> > (mathematical-script . [119964 119990])
> 
> I meant that suggestion as a band-aid fix if we deem that Emacs should
> guard against these "incomplete" fonts.

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.

> > Emacs should probably do the equivalent of 1
> 
> OK; I'll try to follow-up with a bug report and a patch SomeDay™ then.

Thanks.