bug#51495: 29.0.50; [PATCH] Avoid fonts with incomplete coverage of MATHEMATICAL chars

bug#51495: 29.0.50; [PATCH] Avoid fonts with incomplete coverage of MATHEMATICAL chars

[Kévin Le Gouguec]

Hello,

This is a followup to a discussion on help-gnu-emacs[1] which revealed
that script-representative-chars does not account for problematic fonts
like KpMath[2] which provide only partial coverage for the MATHEMATICAL
SCRIPT codepoints U+1D49C–U+1D4CF (𝒜–𝓏).

To be more specific, this font only covers MATHEMATICAL SCRIPT CAPITAL
codepoints and does not cover MATHEMATICAL SCRIPT SMALL codepoints.

Since setup-default-fontset only puts MATHEMATICAL SCRIPT CAPITAL A in
script-representative-chars, Emacs fails to ensure that the fonts
returned by Fontconfig also provide glyphs for SMALL codepoints.

As soon as I get a bug number, I'll followup with a patch (reviewed by
Eli[3]) that deals with the situation by adding both ends of each
"math-subgroup" to script-representative-chars, using lists rather than
vectors to make each codepoint mandatory.

From the discussion, it seems that this problem is not very common (the
gap in KpMath seems very uncommon[2]), and has multiple workarounds
(uninstalling the font, tweaking fontconfig rules, tweaking fontsets),
so although the patch applies to both master and emacs-28, I guess there
is no pressing need to have this on the release branch, and master would
be more appropriate?

Thank you for your time.


[1] help-gnu-emacs <878s02u5m6.fsf@gmail.com>
    https://lists.gnu.org/archive/html/help-gnu-emacs/2021-09/msg00150.html

[2] http://mirrors.ctan.org/fonts/kpfonts-otf/doc/unimath-kpfonts.pdf
    § 15.1.7, 15.1.8

[3] help-gnu-emacs <83k0jjcsal.fsf@gnu.org>
    https://lists.gnu.org/archive/html/help-gnu-emacs/2021-09/msg00192.html


In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.30, cairo version 1.16.0)
 of 2021-10-26 built on amdahl30
Repository revision: f56408a6f0152cd46d1ea8a0985fbfeeb839ea06
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12013000
System Description: openSUSE Tumbleweed

bug#51495: 29.0.50; [PATCH] Avoid fonts with incomplete coverage of MATHEMATICAL chars

[Kévin Le Gouguec]

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

And the Patch That Was Promised, slightly polished compared to the one
posted in help-gnu-emacs[1].

I know that debbugs.el does not make it easy[2], but it'd be nice if the
rationale (the bit between the summary line and the changelog entries)
made it into the final commit message.  It's not essential, since I
added an explanatory comment to the code so that one can find the
rationale without reaching for the changelog, but the proposed commit
message also provides further references if needed.

Again, thanks for your time.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Avoid-fonts-with-incomplete-coverage-of-MATHEMATICAL.patch --]
[-- Type: text/x-patch, Size: 2286 bytes --]

From 73d82879c3516444888ec613a72fa27119fd7851 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?K=C3=A9vin=20Le=20Gouguec?= <kevin.legouguec@gmail.com>
Date: Mon, 11 Oct 2021 23:32:28 +0200
Subject: [PATCH] Avoid fonts with incomplete coverage of MATHEMATICAL chars

Some fonts include glyphs for MATHEMATICAL SCRIPT CAPITAL codepoints
(#x1D49C-#x1D4B5) but not for MATHEMATICAL SCRIPT SMALL codepoints
(#x1D4B6-#x1D4CF), see e.g. KpMath[1].

'script-representative-chars' must thus include both CAPITAL and SMALL
codepoints to ensure that we filter those fonts out.

Bug#51495; discussed in help-gnu-emacs[2].

[1] https://mirrors.ctan.org/fonts/kpfonts-otf/doc/unimath-kpfonts.pdf

[2] <878s02u5m6.fsf@gmail.com>
    https://lists.gnu.org/archive/html/help-gnu-emacs/2021-09/msg00150.html

* lisp/international/fontset.el (setup-default-fontset): Include both
ends of each sub-range in 'script-representative-chars'.
---
 lisp/international/fontset.el | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/lisp/international/fontset.el b/lisp/international/fontset.el
index fcd22e09d2..7c3a7cd1a9 100644
--- a/lisp/international/fontset.el
+++ b/lisp/international/fontset.el
@@ -816,11 +816,16 @@ setup-default-fontset
 			   (#x1D7EC #x1D7F5 mathematical-sans-serif-bold)
 			   (#x1D7F6 #x1D7FF mathematical-monospace)))
     (let ((slot (assq (nth 2 math-subgroup) script-representative-chars)))
+      ;; Add both ends of each subgroup to help filter out some
+      ;; incomplete fonts, e.g. those that cover MATHEMATICAL SCRIPT
+      ;; CAPITAL glyphs but not MATHEMATICAL SCRIPT SMALL ones.
       (if slot
-	  (if (vectorp (cdr slot))
-	      (setcdr slot (vconcat (cdr slot) (vector (car math-subgroup))))
-	    (setcdr slot (vector (cadr slot) (car math-subgroup))))
-	(setq slot (list (nth 2 math-subgroup) (car math-subgroup)))
+          (setcdr slot (append (list (nth 0 math-subgroup)
+                                     (nth 1 math-subgroup))
+                               (cdr slot)))
+        (setq slot (list (nth 2 math-subgroup)
+                         (nth 0 math-subgroup)
+                         (nth 1 math-subgroup)))
 	(nconc script-representative-chars (list slot))))
     (set-fontset-font
      "fontset-default"
-- 
2.33.0


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



[1] Added an explanatory comment; used nth consistently instead of
    car/cadr/nth to make the logic more obvious.

    (pcase-dolist would make it even more obvious; should I send a
    followup patch or would that be overkill?)

[2] One of the many reasons it took me… gee, more than a month? to post
    this patch, is my (on-and-off, still ongoing) attempt to teach
    debbugs-gnu.el to keep this rationale, since it's been stripped from
    my previous patches[3][4][5].

    It's slow going, mostly because I go back and forth between a
    "conservative" approach (introducing a variable similar to
    debbugs-gnu-patch-subject) and an "impotent rage" approach (« Why
    not just call git am??  I made the patch with format-patch, like
    CONTRIBUTE says; why are we even parsing it?!  Is this our lot?  Did
    we fly too close to the sun and burn our wings?  Must we toil
    endlessly, craft regexp after regexp, until the trumpets blow and
    sweet armageddon delivers us from the cycle of re-search-forward?
    What am I (looking-at)?  Hath (eobp) finally come?  (forward-line) I
    go, forever more, UNTIL THE FIRE OF A THOUSAND "^[*]" CLEANSES MY
    CURSED SOUL »).

[3] https://debbugs.gnu.org/35564#231
    Compare with f8d8d28bc6.

[4] https://debbugs.gnu.org/41810#26 (patch 1)
    Compare with elpa.git 01e7d1fe21.

[5] And then there was bug#39504, although the "root cause" for this one
    was attaching more than one patch to a single message.

bug#51495: 29.0.50; [PATCH] Avoid fonts with incomplete coverage of MATHEMATICAL chars

[Lars Ingebrigtsen]

Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:

> And the Patch That Was Promised, slightly polished compared to the one
> posted in help-gnu-emacs[1].

Makes sense to me (and some light testing doesn't show any regressions
here), so I've pushed it to the trunk.

> I know that debbugs.el does not make it easy[2], but it'd be nice if the
> rationale (the bit between the summary line and the changelog entries)
> made it into the final commit message.

Done.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no