On Tue, 2021-03-02 at 13:40 -0800, Ned Freed wrote: > > I like the simple base-emoji rule. After all, to support the full set > > of emojis as per the UTS51, you need Unicode 13 support, which is > > relatively new. > > Let's put this into perspective. Unicode 13 added 5930 characters. The > overwhelming majority of those (4939 characters) were CJK. Only 65 emoji were > added. You can view them here: > > https://unicode.org/emoji/charts-13.0/emoji-released.html > > Obviously experiences vary, but none of these are things I've missed having > available to express a reaction. What? U+1F9A4 \N{dodo} is highly relevant as a reaction! :) But I was a bit confused. For Perl's part, they did not implement emoji properties until 5.32 as part of their incorporation of Unicode 13, since the Unicode Emoji wasn't included in Unicode proper until 13.0. However, Unicode Emoji has, as a related standard, had these mechanisms since its version 2.0 from November 2015. > > E.g, I wanted to try out the Emoji properties in Perl regexps, and I > > found this support was only introduced in Perl 5.32, released in June > > 2020. Similarily, GNU libc got Unicode 13 support in August 2020. > > Given that Unicode 13 was released in March, 2020, that's actually quite > impressive. Well, GNU libc does not have support for the needed parts after all - just the classic parts of Unicode :/ So... access to sufficiently good library support for checking the emoji properties may be spotty. > > So - base-emojis may be helpful to get traction for the extension. But > > the draft only concerns itself with restricting *sending* to base- > > emojis. It does not say explicitly that an implementation which only > > understands received base-emojis is allowed or how it should behave > > when it processes reaction emojis outside its repertoire. > > Possible text, insert new point 4 in processing: > > 4. If the part contains code points outside the implementation's > > vocabulary, it MAY process them as undisplayable. > > I think this assigns the base-emoji set a too much importance in the overall > scheme of things. But if the consensus is otherwise, I can live with it. thanks. -- venleg helsing, Kjetil T. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
