Re: Unicode 13 Emoji ranges composed with wrong font on NS port

[Robert Pluim]

>>>>> On Tue, 12 Oct 2021 21:27:46 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Cc: Jimmy Yuen Ho Wong <wyuenho@gmail.com>,  Alan Third 
<alan@idiocy.org>,
    >> emacs-devel@gnu.org
    >> Date: Tue, 12 Oct 2021 19:13:59 +0200
    >> 
    >> This turns out not to be due to macOS differences, but because of this
    >> code in lisp/composite.el:
    >> 
    >> (let ((elt '([".." 1 compose-gstring-for-variation-glyph])))
    >> (set-char-table-range composition-function-table '(#xFE00 . #xFE0F) elt)
    >> (set-char-table-range composition-function-table '(#xE0100 . #xE01EF) 
elt))
    >> 
    >> If I change that to use `compose-gstring-for-graphic' instead, then
    >> the emoji+VS-16 display works correctly on macOS and GNU/Linux.
    >> 
    >> Eli, something like the following for emacs-28?

    Eli> That's because VS-16 is already handled by other entries, including
    Eli> its own?  Or how will VS-16 be handled if you remove it from that
    Eli> range?

Digging deeper, we could actually remove the VS-16 entry completely,
since itʼs then handled by composite.el:737 :

    (when unicode-category-table
      (let ((elt `([,(purecopy "\\c.\\c^+") 1 compose-gstring-for-graphic]
                   [nil 0 compose-gstring-for-graphic])))

although I think Iʼd prefer to be explicit about it.

    Eli> And if the reason is that VS-16 is not about glyph variations, then
    Eli> why not exempt VS-15 as well?  Or why we need that special entry for
    Eli> VS-16 at all?

I donʼt know the history. I also donʼt know how common fonts which
contain variant glyphs are. Iʼll have to run some experiments.

    >> +;; We don't want variation selectors to be used to look up glyphs for 
FE0F

    Eli> The comment should explain why.  Right now, the comment just says what
    Eli> the code does, but gives no reasons.

Iʼll fix that.

Robert
--