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

[Eli Zaretskii]

> Date: Mon, 11 Oct 2021 22:39:19 +0100
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> From: Jimmy Yuen Ho Wong <wyuenho@gmail.com>
> 
> >      >> #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.

But characters like U+0023 hash sign and U+00A9 copyright sign are
also in emoji-data.txt with the same "Emoji=Yes" property, and yet
that doesn't mean we should treat them as Emoji, right?

These belong to symbols and punctuation, outside of the Emoticons
block, so we decided to treat them as Emoji only when they are
followed by VS-16, which means the text explicitly requests to show
them in their Emoji representation.

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

Please be even more specific: which parts of that screenshot are in
your opinion incorrect, and why?

In general, sequences that end in VS-16 should be displayed as Emoji
if they are designated as such in emoji-sequences.txt and
emoji-zwj-sequences.txt.  See admin/unidata/emoji-zwj.awk.  The rest
we decided not to display as Empji for various good reasons.