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

[Jimmy Yuen Ho Wong]

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)
x270c is Victory Hand, x261d is Index Pointing Up, x270d is Writing 
Hand, and x26f9 is Person Bouncing Ball. They are found in Unicode 14's, 
along with Unicode 13's emoji-data.txt. All of which have been a part of 
Emoji 1.0 from 2015.
>      >> 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 :-)

As the comments in emoji-style.txt states, emojis with 
Emoji_Presentation=False when followed by VS15 (text+ts), should be 
displayed as text, but currently most are displayed as emojis, whereas 
most of those followed by VS16 (text+es) are currently displayed text. 
See the attached screenshot.

Screen Shot 2021-10-11 at 10.35.56 pm.png
Description: PNG image