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

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

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