[issue41622] Add support for emoji-data.txt and emoji-variation-sequences.txt to unicodedata

[Terry J. Reedy]

Terry J. Reedy <tjreedy at udel.edu> added the comment:

Base facts: The Unicode Character Database, UCD, is defined in Tech Report 44, https://www.unicode.org/reports/tr44/.  The latest files (now for 13.0) are at https://www.unicode.org/Public/UCD/latest/ and in particular, in the ucd subdirectory. ucd/UnicodeData.txt has a sequential list of current codepoints, including emoji codepoints.

Version 13 added subdirectly ucd/emoji with the 2 files listed above.  emoji-variation-sequences.txt comprises 177 highly redundant pairs of lines like this:
0023 FE0E  ; text style;  # (1.1) NUMBER SIGN
0023 FE0F  ; emoji style; # (1.1) NUMBER SIGN
The only difference between the lines is 'FE0E; text' versus 'FE0F; emoji', 'TEXT PRESENTATION SELECTOR' versus 'EMOJI PRESENTATION SELECTOR'.

tr51 does not explicitly say that every line is paired, but perusal suggests that this is true, making the file highly redundant.  The 177 characters include some non-emoji symbols, like #, and omits most emoji, including SNAKE, '\U0001f40d', '🐍' (colored coiled snake). And yet, here, at least in Firefox, is the supposedly invalid text snake, '\U0001f40d\ufe0e': '🐍︎' (a flat black-only, uncoiled wiggling snake head).  I don't know how '#\ufe0f' might be different from plain '#'.

Our UCD copy is accessed via 13 functions in the unicodedata module.  Support for the file could consist of a new function, such as 'emoji_text'.  The implementation could be 'chr in emoji_text_set', where the latter is the set of 177 characters.  But given the accidental experiment above with an unauthorized sequence, I don't know how useful it would be.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41622>
_______________________________________