This page is a compilation of formal public feedback received so far. See Feedback for further information on this issue, how to discuss it, and how to provide feedback.
Feedback above this line reviewed during UTC #178 in January 2024.
Date/Time: Thu Jan 18 17:50:43 CST 2024
ReportID: ID20240118175043
Name: Alan Baljeu
Report Type: Public Review Issue
Opt Subject: 496
Some time ago, U+265F BLACK CHESS PAWN was added as an emoji. No other chess pieces U+265n were designated as emoji. The effect of this has been to break the appearance of many font-based renderings of chess. What happens is figuring algebraic chess notation and drawings of boards done with html, and other techniques has 11 normal looking piece types, and one emoji looking piece, because one member of a set was given a different designation. An illustrative example can be seen at https://en.wikipedia.org/wiki/Chess_symbols_in_Unicode. The image of the unicode pieces in various fonts looks fine (it probably was created before the emoji designation), but the image of the GNU chess board does not. Observe the black pawns look very different from the white pawn, and unlike the picture above. Possibly this can be resolved by dozens of individual applications including web browsers and/or thousands of web pages by specifying a variant character. Possibly by changing this set of characters to be uniformly designated (not 1 different).
Date/Time: Fri May 24 19:30:11 CDT 2024
ReportID: ID20240524193011
Name: Jules Bertholet
Report Type: Public Review Issue
Opt Subject: 496
UTS 51 states: > # C.1 Flag Emoji Tag Sequences > > A valid flag emoji tag sequence must satisfy the following constraints: > > 1. The `tag_base` and `tag_spec` are limited to the following: > > `tag_base` U+1F3F4 BLACK FLAG > `tag_spec` (U+E0030 TAG DIGIT ZERO .. U+E0039 TAG DIGIT NINE, > U+E0061 TAG LATIN SMALL LETTER A .. U+E007A TAG LATIN SMALL LETTER Z)+ > > `tag_end` is U+E007F CANCEL TAG, as described in ED-14a. > > 2. Let SD be the result of mapping each character in the tag_spec to a character in [0-9a-z] by subtracting 0xE0000. > 1. SD must then be a specification as per [CLDR] of either a Unicode subdivision_id or a 3-digit unicode_region_subtag, and > 2. SD must have CLDR idStatus = “regular”, “deprecated”, or “macroregion”.> The definition of validity for emoji flag sequences, and therefore for emoji as a whole, thereby depends on CLDR data. However, CLDR is versioned and released separately from the Unicode Standard and UTS 51. Must am implementation claiming conformance to UTS 51(for example, a program that checks whether a string is a valid emoji) therefore specify not only the Unicode version it conforms to, but also the CLDR version? If so, this should be specified in §1.5, "Conformance". Alternately, the validity definition should be changed so as not to depend on CLDR data, or to specify a specific version or CLDR.
Date/Time: Mon Jun 17 11:13:43 CDT 2024
ReportID: ID20240617111343
Name: Jules Bertholet
Report Type: Public Review Issue
Opt Subject: 496
UTS 51 describes the `Emoji_Presentation` property like so: > Emoji_Presentation EPres =Yes for characters that have emoji presentation by default. It also says the following about the regional indicators (under §1.4.6): > Regional Indicators […] should never have an emoji presentation in > isolation […]. These are not included in Basic_Emoji. Therefore, the `Regional_Indicator` characters should not have the `Emoji_Presentation` property. However, they currently do; this should be corrected. Performing this change would also allow simplifying definition ED-4 in UAX 11 ( https://www.unicode.org/reports/tr11/proposed.html#ED4 ).