Emoji anomaly

[Andre Schappo via Unicode]

Peter

Thank you very much for your informative response. I see that U+1F321 ➜ U+1F32C do not have Emoji_Presentation property set. Time for me to do some reading to determine why.

André

On 29 Oct 2017, at 00:20, Peter Edberg <pedberg at unicode.org<mailto:pedberg at unicode.org>> wrote:

This is about characters U+1F327,U+1F326

The variation selector FE0F is *not* unnecessary in with these. Looking at
https://www.unicode.org/Public/emoji/5.0/emoji-data.txt
those characters do *not* have the Emoji-Presentation property set, and they do have variation sequences defined.

From https://www.unicode.org/reports/tr51/#Emoji_Variation_Selector_Notes, such singleton emoji characters
“should have emoji presentation selectors on base characters with Emoji_Presentation=No whenever an emoji presentation is desired”

- Peter E

On Oct 28, 2017, at 4:11 AM, Andre Schappo via Unicode <unicode at unicode.org<mailto:unicode at unicode.org>> wrote:


I am working on a Blog Article ( https://schappo.blogspot.co.uk/2017/10/computer-science-internationalization.html ) and do not currently have access to OSX High Sierra, I am using OSX Sierra. I would appreciate some help from someone using OSX High Sierra.

Using Sierra's Chinese Simplified Input Method the Emoji ��️ and ��️ have an unnecessary U+FE0F variation selector appended. The other Emoji I have tested with Sierra's Chinese Simplified Input Method do not have the variation selector appended. Could someone please check if the same happens with High Sierra

Thank you

André
�� �� ��
André Schappo
https://schappo.blogspot.co.uk<https://schappo.blogspot.co.uk/>
https://twitter.com/andreschappo
https://weibo.com/andreschappo
https://groups.google.com/forum/#!forum/computer-science-curriculum-internationalization






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://unicode.org/pipermail/unicode/attachments/20171029/93cd0be4/attachment.html>