Re: script-representative-chars vs incomplete fonts

["Kévin Le Gouguec" <kevin.legouguec@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1615 bytes --]

Thanks for your insights, Eli!  Some follow-up thoughts & questions.

Eli Zaretskii <eliz@gnu.org> writes:

>> On my system, I happen to have
>> 
>> - one font (KpMath) that provides U+1D49C–U+1D4B5 (the "capital" chars),
>>   but not U+1D4B6–U+1D4CF (the "small" chars),
>> 
>> - another font (DejaVu Math TeX Gyre) that provides both sub-ranges[1].
>> 
>> As luck would have it, when trying to display a char in this range,
>> Emacs stumbles on KpMath first
>
> 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?

So I'm not sure there's a bug on fontconfig's end?  FWIW the CLI tools
seem to provide accurate information[1].

>> E.g. in fontset.el, would it be overkill to break down the 52-char
>> ranges in the math-subgroup loop into 2 26-char ranges in order to
>> always add the "SMALL A" codepoints to script-representative-chars?
>
> 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:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 667 bytes --]

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)

[-- Attachment #3: Type: text/plain, Size: 2026 bytes --]


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.

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?

>>     1. (push #x1D4CF (alist-get 'mathematical-script
>>                                 script-representative-chars))
>>     2. (set-fontset-font
>>         t 'mathematical "DejaVu Math TeX Gyre" nil 'prepend)
>>     3. Uninstall KpMath.
>
> I'd suggest to do 3 regardless.  A font that supports only part of a
> block is a bad font to have.

(Right; AFAICT KpMath got pulled in when I installed TeXLive.  I'm not
entirely sure why the font was designed this way; I couldn't find a
rationale in the documentation hosted on CTAN[2])

> Emacs should probably do the equivalent of 1

OK; I'll try to follow-up with a bug report and a patch SomeDay™ then.


Again, thanks for your explanations.


[1]
$ fc-list ':charset=1d4c1'
⇒ a bunch of fonts, including DejaVu Math TeX Gyre but *not* KpMath

$ fc-match -f '%{charset}\n' 'KpMath'
… 1d456-1d49c 1d49e-1d49f 1d4a2 1d4a5-1d4a6 1d4a9-1d4ac 1d4ae-1d4b5
1d4d0-1d4e9 …
⇒ includes U+1D49C–U+1D4B5 (minus nonexistent codepoints) but not
  U+1D4B6–U+1D4CF

$ fc-match -f '%{charset}\n' 'DejaVu Math TeX Gyre'
… 1d456-1d49c 1d49e-1d49f 1d4a2 1d4a5-1d4a6 1d4a9-1d4ac 1d4ae-1d4b9
1d4bb 1d4bd-1d4c3 1d4c5-1d505…
⇒ includes U+1D49C–U+1D4B5 *and* U+1D4B6–U+1D4CF (minus nonexistent
  codepoints)

[2]
https://ctan.org/pkg/kpfonts
https://ctan.org/pkg/kpfonts-otf

The "List of glyphs" document from this second page, § 15.1.8, features
a table that clearly shows that KpMath (column "K") does not contain the
lowercase glyphs, but I fail to find a design rationale.