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

[Robert Pluim]

>>>>> On Wed, 13 Oct 2021 15:58:19 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Cc: alan@idiocy.org,  wyuenho@gmail.com,  emacs-devel@gnu.org
    >> Date: Wed, 13 Oct 2021 11:35:22 +0200
    >> 
    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> Why do you prefer that?

I was thinking it would be better to give more information to later
maintainers, but the explicit entry would need to be the same as
what's already there, so best to leave it alone.

    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.

    Eli> But VS-15 is not about variant glyphs, it's about requesting the "text
    Eli> representation" of certain characters, including Emoji.  So it sounds
    Eli> like the rule for compose-gstring-for-variation-glyph is not really
    Eli> relevant for it, as well as for VS-16.  Right?

The VS-15 rule actually needs to continue to use
compose-gstring-for-variation-glyph, because if I change it to use
compose-gstring-for-graphic, the font_range change kicks in, and Emacs
displays the Emoji presentation for codepoints followed by VS-15.

Robert
--