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

[Robert Pluim]

>>>>> On Mon, 11 Oct 2021 22:39:19 +0100, Jimmy Yuen Ho Wong 
>>>>> <wyuenho@gmail.com> said:

    Jimmy> On 10/10/2021 4:49 PM, Robert Pluim wrote:
    >>>>>>> On Sun, 10 Oct 2021 13:52:01 +0300, Eli Zaretskii <eliz@gnu.org> 
said:
    >> >> Date: Sun, 10 Oct 2021 09:27:17 +0100
    >> >> From: Jimmy Yuen Ho Wong <wyuenho@gmail.com>
    >> >>
    >> >> However, despite what the NEWS file claims, I was visiting Unicode 
13's emoji-style.txt downloaded from
    >> >> here and noticed that certain composed character in the modifier and 
zwj blocks do not compose using
    >> >> Apple Color Emoji on the NS port running on macOS 11, but somehow 
went to Symbola, even after setting
    >> >> (set-fontset-font t 'emoji '("Apple Color Emoji"
    >> >> . "iso10646-1") nil 'prepend). Specifically, the characters
    >> >> are
    >> >> #x270c, #x261d, #x270d, and #x26f9.
    >> >>
    >> 
    >> As Eli mentions below, theyʼre not emoji (in Emacs, at least)
    Jimmy> x270c is Victory Hand, x261d is Index Pointing Up, x270d is Writing
    Jimmy> Hand, and x26f9 is Person Bouncing Ball. They are found in Unicode
    Jimmy> 14's, along with Unicode 13's emoji-data.txt. All of which have been 
a
    Jimmy> part of Emoji 1.0 from 2015.
    >>

You missed the "in Emacs" qualifier in what I wrote.

    >> >> I also noticed that Emoji Presentation isn't handled correctly 
according to spec yet, tho much closer than
    >> >> most browers except Firefox.
    >> >>
    >> 
    >> You'll have to be more specific. Details matter when dealing with
    >> Unicode :-)

    Jimmy> As the comments in emoji-style.txt states, emojis with
    Jimmy> Emoji_Presentation=False when followed by VS15 (text+ts), should be
    Jimmy> displayed as text, but currently most are displayed as
    Jimmy> emojis, whereas

They are? Thatʼs not what Iʼm seeing in your screenshot (nor
locally). And Emacs does nothing with VS15 for now.

    Jimmy> most of those followed by VS16 (text+es) are currently displayed
    Jimmy> text. See the attached screenshot.

On Gnu/Linux with Noto Color Emoji they all look very colourful. For
some reason on macOS the code thatʼs supposed to handle VS16 is not
working correctly.

Hmm, the bit in font_range that does the lookup based off
Vscript_representative_chars is working correctly, which means Iʼll
need to look into the macOS font/display code. Given that
glyphless-char-display appears not to be honored on macOS, maybe
thereʼs some code missing. Alan?

Robert
--