The sections below contain links to permanent feedback documents for the open Public Review Issues as well as other public feedback as of May 02, 2017, since the previous cumulative document was issued prior to UTC #150 (January 2017). Some items in the Table of Contents do not have feedback here.
The links below go directly to open PRIs and to feedback documents for them, as of May 02, 2017.
The links below go to locations in this document for feedback.
Feedback to UTC / Encoding Proposals
Feedback on UTRs / UAXes
Error Reports
Other Reports
Note: The section of Feedback on Encoding Proposals this time includes:
L2/17-056
L2/17-071
L2/17-077
L2/17-078
L2/17-086
L2/17-091
L2/17-092
L2/17-113
Date/Time: Fri Mar 24 04:14:52 CDT 2017
Name: Christoph Päper
Report Type: Feedback on an Encoding Proposal
Opt Subject: L2/17-071 Gender-Neutral Human-form Emoji
(This has already been sent to the ESC)
> > 3.d.iii. U+1F9D5 person with headscarf Unlike other role, profession and activity sequences, Office Worker and Swimmer emojis are wearing different clothes in all current implementations of Emoji 4.0+. - 👨💼 http://emojipedia.org/male-office-worker/ - 👩💼 http://emojipedia.org/female-office-worker/ - 🏊♂️ http://emojipedia.org/man-swimming/ - 🏊♀️ http://emojipedia.org/woman-swimming/ These are *cultural conventions*, whereas U+1F930 Pregnant Woman and U+1F931 Breast Feeding have no male counterpart for *biological reasons*. (I'm not sure about U+1F9D4 Bearded Person.) Wearing a headscarf is also just a cultural thing which is not limited to women (cf. stereotypical sheikhs). The selection factors for 3.d. hence are a non-sequitur. Similar considerations apply to U+1F473 Man with Turban and U+1F472 Man with Gua Pi Mao. Both types of headwear are traditionally only worn by men. The original JCarrier emojis were obviously intended as stereotypical representations of Chinese and Indian men (or people). Likewise, U+1F471 Person with Blond Hair (and Long Nose) was really a stereotypical European/Western person. One could argue that, for instance, new Woman with Bindu and Geisha characters could be female counterparts for U+1F473/2. This would actually already cover stereotypes for 4 out of 5 emoji skin tone modifiers, i.e. a Person with Afro Hairdo or something like that would be needed to not further discriminate against the darkest skin tone. Another often overlooked emoji with gender representation issues is U+1F6B9 Mens Symbol and, less so, U+1F6BB Restroom. They are usually showing an abstract stick figure without any gender-specific attributes. It only becomes a representation of a man when put into contrast to a woman, i.e. either internal in U+1F6BB or with external U+1F6BA Womens Symbol nearby, which is usually indicated by a skirt as a culturally gender-specific token. You might want to consider to add a recommendation to vendors for making U+1F6BB a truly neutral variant and U+1F6B9 more obviously male.
Date/Time: Sat Apr 8 11:16:25 CDT 2017
Name: Ken Lunde
Report Type: Feedback on an Encoding Proposal
Opt Subject: L2/17-092 feedback
Although I did not submit a formal proposal, I would like to point out that I raised the possibility of encoding these two characters in June of 2011 on the "unicore" mailing list, and the discussion ended by stating that the existing upper and lowercase Roman numerals were encoded for compatibility with legacy standards, specifically East Asian ones. My interest in this is that the Adobe-Japan1-6 character collection includes glyphs for these two characters. -- Ken
Date/Time: Mon Apr 10 16:01:33 CDT 2017
Name: Christoph Päper
Report Type: Feedback on an Encoding Proposal
Opt Subject: L2/17-086 Emoji_Component
No emoji implementation is know to currently do so, but UTR#51 has been mentioning the possibility to use arbitrary combining characters with emoji characters, U+20E0 COMBINING ENCLOSING CIRCLE BACKSLASH in particular (which matches the emoji character U+1F6AB No Entry Sign). The UTC/ESC should consider to amend this proposal to include at least this combining character.
Date/Time: Sat Apr 15 11:51:54 CDT 2017
Name: Ken Lunde
Report Type: Feedback on an Encoding Proposal
Opt Subject: Feedback on L2/17-091 and small kana
If we were to accept Japan's suggestion in L2/17-091 to completely map out the missing small kana and to reserve a block for them, then encoding them as proposals come in and are accepted, the number of necessary code points appears to be 56. 36 of these correspond to small hiragana (small versions of きくこ*さしすせそたちてとなにぬねのはひふへほまみむめもらりるれろゐ*ゑ*を*ん -- asterisks follow those that are currently in the pipeline), and the remaining 20 correspond to small katakana (small versions of キコ*サセソタチテナニネノマミメモヰ*ヱ*ヲ*ン* -- asterisks follow those that are currently in the pipeline). Their character names would be as follows (the nine that are currently in the pipeline are marked with their tentative code points): HIRAGANA LETTER SMALL KI HIRAGANA LETTER SMALL KU HIRAGANA LETTER SMALL KO (U+1B127) HIRAGANA LETTER SMALL SA HIRAGANA LETTER SMALL SI HIRAGANA LETTER SMALL SU HIRAGANA LETTER SMALL SE HIRAGANA LETTER SMALL SO HIRAGANA LETTER SMALL TA HIRAGANA LETTER SMALL TI HIRAGANA LETTER SMALL TE HIRAGANA LETTER SMALL TO HIRAGANA LETTER SMALL NA HIRAGANA LETTER SMALL NI HIRAGANA LETTER SMALL NU HIRAGANA LETTER SMALL NE HIRAGANA LETTER SMALL NO HIRAGANA LETTER SMALL HA HIRAGANA LETTER SMALL HI HIRAGANA LETTER SMALL HU HIRAGANA LETTER SMALL HE HIRAGANA LETTER SMALL HO HIRAGANA LETTER SMALL MA HIRAGANA LETTER SMALL MI HIRAGANA LETTER SMALL MU HIRAGANA LETTER SMALL ME HIRAGANA LETTER SMALL MO HIRAGANA LETTER SMALL RA HIRAGANA LETTER SMALL RI HIRAGANA LETTER SMALL RU HIRAGANA LETTER SMALL RE HIRAGANA LETTER SMALL RO HIRAGANA LETTER SMALL WI (U+1B128) HIRAGANA LETTER SMALL WE (U+1B129) HIRAGANA LETTER SMALL WO (U+1B12A) HIRAGANA LETTER SMALL N KATAKANA LETTER SMALL KI KATAKANA LETTER SMALL KO (U+ 1B12B) KATAKANA LETTER SMALL SA KATAKANA LETTER SMALL SE KATAKANA LETTER SMALL SO KATAKANA LETTER SMALL TA KATAKANA LETTER SMALL TI KATAKANA LETTER SMALL TE KATAKANA LETTER SMALL NA KATAKANA LETTER SMALL NI KATAKANA LETTER SMALL NE KATAKANA LETTER SMALL NO KATAKANA LETTER SMALL MA KATAKANA LETTER SMALL MI KATAKANA LETTER SMALL ME KATAKANA LETTER SMALL MO KATAKANA LETTER SMALL WI (U+ 1B12C) KATAKANA LETTER SMALL WE (U+ 1B12D) KATAKANA LETTER SMALL WO (U+ 1B12E) KATAKANA LETTER SMALL N (U+ 1B12F) That is all.
Date/Time: Thu Apr 20 16:45:37 CDT 2017
Name: Christoph Päper
Report Type: Feedback on an Encoding Proposal
Opt Subject: [L2/17-056] Use VS-16 instead of VS-3 = East Asian Fullwidth Form and VS-2 = Centered Form
Assuming UTS#51 will soon feature a useful definition of what kind of presentation is "Emoji" (i.e. colorful optional but common, ideographic grid mandatory), this proposal may be able to reuse the conventional semantics associated with VS-16, although variation selectors are generally considered to be meaningless without their entry in StandardizedSequences.txt. In other words, emoji glyphs are always presented in a square em cell and this is the desired behavior of the "East Asian Fullwidth" column, so the emoji variation selector VS-16 could be used instead of VS-3. Emojis are usually also centered horizontally and vertically within the character cell, which is also desired for the affected characters, except for the quotation marks, and it is also what the second table is all about, so the use of VS-2 there could also be substituted by VS-16. The default (Western) form which is using VS-1 in the proposal could also be changed to VS-15, but that's probably less convincing. To be more systematic, VS-2 should then be replaced by VS-14. # Western form, East Asian form, and East Asian fullwidth form variation sequences 0021 FE0E; Western form; # EXCLAMATION MARK 0021 FE0D; East Asian form; # EXCLAMATION MARK 0022 FE0E; Western form; # QUOTATION MARK 0022 FE0D; East Asian form; # QUOTATION MARK 0027 FE0E; Western form; # APOSTROPHE 0027 FE0D; East Asian form; # APOSTROPHE 0028 FE0E; Western form; # LEFT PARENTHESIS 0028 FE0D; East Asian form; # LEFT PARENTHESIS 0029 FE0E; Western form; # RIGHT PARENTHESIS 0029 FE0D; East Asian form; # RIGHT PARENTHESIS 002C FE0E; Western form; # COMMA 002C FE0D; East Asian form; # COMMA 002D FE0E; Western form; # HYPHEN-MINUS 002D FE0D; East Asian form; # HYPHEN-MINUS 002E FE0E; Western form; # FULL STOP 002E FE0D; East Asian form; # FULL STOP 002F FE0E; Western form; # SOLIDUS 002F FE0D; East Asian form; # SOLIDUS 0030 FE0E; Western form; # DIGIT ZERO 0030 FE0D; East Asian form; # DIGIT ZERO 0031 FE0E; Western form; # DIGIT ONE 0031 FE0D; East Asian form; # DIGIT ONE 0032 FE0E; Western form; # DIGIT TWO 0032 FE0D; East Asian form; # DIGIT TWO 0033 FE0E; Western form; # DIGIT THREE 0033 FE0D; East Asian form; # DIGIT THREE 0034 FE0E; Western form; # DIGIT FOUR 0034 FE0D; East Asian form; # DIGIT FOUR 0035 FE0E; Western form; # DIGIT FIVE 0035 FE0D; East Asian form; # DIGIT FIVE 0036 FE0E; Western form; # DIGIT SIX 0036 FE0D; East Asian form; # DIGIT SIX 0037 FE0E; Western form; # DIGIT SEVEN 0037 FE0D; East Asian form; # DIGIT SEVEN 0038 FE0E; Western form; # DIGIT EIGHT 0038 FE0D; East Asian form; # DIGIT EIGHT 0039 FE0E; Western form; # DIGIT NINE 0039 FE0D; East Asian form; # DIGIT NINE 003A FE0E; Western form; # COLON 003A FE0D; East Asian form; # COLON 003B FE0E; Western form; # SEMICOLON 003B FE0D; East Asian form; # SEMICOLON 003F FE0E; Western form; # QUESTION MARK 003F FE0D; East Asian form; # QUESTION MARK 005B FE0E; Western form; # LEFT SQUARE BRACKET 005B FE0D; East Asian form; # LEFT SQUARE BRACKET 005D FE0E; Western form; # RIGHT SQUARE BRACKET 005D FE0D; East Asian form; # RIGHT SQUARE BRACKET 007B FE0E; Western form; # LEFT CURLY BRACKET 007B FE0D; East Asian form; # LEFT CURLY BRACKET 007D FE0E; Western form; # RIGHT CURLY BRACKET 007D FE0D; East Asian form; # RIGHT CURLY BRACKET 007E FE0E; Western form; # TILDE 007E FE0D; East Asian form; # TILDE 00B7 FE0E; Western form; # MIDDLE DOT 00B7 FE0D; East Asian form; # MIDDLE DOT 2011 FE0E; Western form; # NON-BREAKING HYPHEN 2011 FE0D; East Asian form; # NON-BREAKING HYPHEN 2012 FE0E; Western form; # FIGURE DASH 2012 FE0D; East Asian form; # FIGURE DASH 2013 FE0E; Western form; # EN DASH 2013 FE0D; East Asian form; # EN DASH 2014 FE0E; Western form; # EM DASH 2014 FE0D; East Asian form; # EM DASH 2014 FE0F; East Asian fullwidth form; # EM DASH 2018 FE0E; Western form; # LEFT SINGLE QUOTATION MARK 2018 FE0D; East Asian form; # LEFT SINGLE QUOTATION MARK 2018 FE0F; East Asian fullwidth form; # LEFT SINGLE QUOTATION MARK 2019 FE0E; Western form; # RIGHT SINGLE QUOTATION MARK 2019 FE0D; East Asian form; # RIGHT SINGLE QUOTATION MARK 2019 FE0F; East Asian fullwidth form; # RIGHT SINGLE QUOTATION MARK 201A FE0E; Western form; # SINGLE LOW-9 QUOTATION MARK 201A FE0D; East Asian form; # SINGLE LOW-9 QUOTATION MARK 201C FE0E; Western form; # LEFT DOUBLE QUOTATION MARK 201C FE0D; East Asian form; # LEFT DOUBLE QUOTATION MARK 201C FE0F; East Asian fullwidth form; # LEFT DOUBLE QUOTATION MARK 201D FE0E; Western form; # RIGHT DOUBLE QUOTATION MARK 201D FE0D; East Asian form; # RIGHT DOUBLE QUOTATION MARK 201D FE0F; East Asian fullwidth form; # RIGHT DOUBLE QUOTATION MARK 201E FE0E; Western form; # DOUBLE LOW-9 QUOTATION MARK 201E FE0D; East Asian form; # DOUBLE LOW-9 QUOTATION MARK 2026 FE0E; Western form; # HORIZONTAL ELLIPSIS 2026 FE0D; East Asian form; # HORIZONTAL ELLIPSIS 2026 FE0F; East Asian fullwidth form; # HORIZONTAL ELLIPSIS 203C FE0E; Western form; # DOUBLE EXCLAMATION MARK 203C FE0D; East Asian form; # DOUBLE EXCLAMATION MARK 203C FE0F; East Asian fullwidth form; # DOUBLE EXCLAMATION MARK 2047 FE0E; Western form; # DOUBLE QUESTION MARK 2047 FE0D; East Asian form; # DOUBLE QUESTION MARK 2047 FE0F; East Asian fullwidth form; # DOUBLE QUESTION MARK 2048 FE0E; Western form; # QUESTION EXCLAMATION MARK 2048 FE0D; East Asian form; # QUESTION EXCLAMATION MARK 2048 FE0F; East Asian fullwidth form; # QUESTION EXCLAMATION MARK 2049 FE0E; Western form; # EXCLAMATION QUESTION MARK 2049 FE0D; East Asian form; # EXCLAMATION QUESTION MARK 2049 FE0F; East Asian fullwidth form; # EXCLAMATION QUESTION MARK 2E3A FE0E; Western form; # TWO-EM DASH 2E3A FE0D; East Asian form; # TWO-EM DASH 2E3A FE0F; East Asian fullwidth form; # TWO-EM DASH 2E3B FE0E; Western form; # THREE-EM DASH 2E3B FE0D; East Asian form; # THREE-EM DASH 2E3B FE0F; East Asian fullwidth form; # THREE-EM DASH # Left-justified form and centered form variation sequences 3001 FE0E; left-justified form; # IDEOGRAPHIC COMMA 3001 FE0F; centered form; # IDEOGRAPHIC COMMA 3002 FE0E; left-justified form; # IDEOGRAPHIC FULL STOP 3002 FE0F; centered form; # IDEOGRAPHIC FULL STOP FF01 FE0E; left-justified form; # FULLWIDTH EXCLAMATION MARK FF01 FE0F; centered form; # FULLWIDTH EXCLAMATION MARK FF0C FE0E; left-justified form; # FULLWIDTH COMMA FF0C FE0F; centered form; # FULLWIDTH COMMA FF0E FE0E; left-justified form; # FULLWIDTH FULL STOP FF0E FE0F; centered form; # FULLWIDTH FULL STOP FF1A FE0E; left-justified form; # FULLWIDTH COLON FF1A FE0F; centered form; # FULLWIDTH COLON FF1B FE0E; left-justified form; # FULLWIDTH SEMICOLON FF1B FE0F; centered form; # FULLWIDTH SEMICOLON FF1F FE0E; left-justified form; # FULLWIDTH QUESTION MARK FF1F FE0F; centered form; # FULLWIDTH QUESTION MARK
Date/Time: Thu Apr 27 12:12:17 CDT 2017
Name: Kushim Jiang
Report Type: Feedback on an Encoding Proposal
Opt Subject: Comment on L2/17-113
1. Actually when we use a PETRI DISH, the bacteria should be grown over a layer of culture media, which can't be shown according to the picture. So the picture of PETRI DISH should be corrected. 2. When PI is located with the atom symbol, PI should mean PION, a kind of elementary particle. So there should be TAUON in the block for equality, or the PI should be deleted because there isn't a kind of specific variant for the elementary particle.
Date/Time: Sun Apr 30 22:10:29 CDT 2017
Name: Christoph Päper
Report Type: Feedback on an Encoding Proposal
Opt Subject: [L2/17-077] Use VS-16 instead of VS-1 and VS-2
The title of L2/17-077 = [N4793] reads "Proposal to add standardized variation
sequences for chess notation", but it is really about the distinction between
chess game notation (i.e. moves) and chess board diagrams (i.e. positions).
Move notation, in European writing systems at least, works well with
proportional figurine glyphs sitting on the baseline. Position diagrams would
benefit from square glyphs with the pieces centered vertically and
horizontally within them.
Only 2D diagrams (and hence classic typefaces intended to typeset them)
regularly use the characteristic "white" and "black" backgrounds of
checkerboards, because in game notation, that information is encoded in the
[A-H][1-8] coordinates used ubiquitously. In print books, "black" is in fact
usually rendered as a diagonal hatching pattern akin U+25A8 ▨, which is
visually less heavy. Alas, this hatching pattern is elsewhere associated with
a purple, green or orange color ('purpure', 'vert' or 'orange' tincture), cf.
[N4011], [Wikicommons].
I agree with the proposal in principle, i.e. that there should be variation
sequences for existing and future chess piece characters in Unicode (cf.
L2/17-033 and 034). I strongly believe, however, that it should reuse
variation selectors VS-15 and VS-16 as canonically used for text-style and
emoji-style, respectively, instead of more arbitrary VS-1 and VS-2.
Precedents
----------
The emoji font used by Samsung, and thus on millions of devices, has colorful
bitmap glyphs for the Unicode chess pieces U+2654..F, as documented before for
[L2/16-087]/[L2/16-088]. They are "colorful" in that they are always rendered
in solid black and white, not the local foreground and backgrounds colors,
which would be the behavior for the classic Unicode terms "Black" (solid) and
"White" (hollow).
[My First HDML] is the only resource I could find which asserts that the now
[defunct Openwave Mobile Browser 6.2, as used by the Japanese telecom provider
[KDDI au, also supported chess pieces, using numeric codes 577 through 588.
[Documented emoji sets KDDI D] and KDDI F] consistently show a gap between 518
[and 700. Archived Openwave] documentation only mentions additions at 500
[through 561:
>>Icons 1 to 175 and 500 to 536 are supported by Openwave Mobile Browser
6.1 and 6.2; 537 to 561 are supported by 6.2 only. I could neither find
documentation on Openwave 7.x nor successfully get to work an emulator of
theirs.
Chess pieces have been proposed before to gain `Emoji` status in [L2/16-021].
Related action item 146-A108 has been closed 2016-05-15, but from the
documentation publicly available it is not clear to me how it has been
resolved.
There are several pairs of emoji characters for black and white squares. The
full-size ones, U+2B1B/C seem most appropriate and have default emoji
presentation.
Emoji Presentation
------------------
UTS51 is still a bit unclear about what "emoji presentation" actually means exactly.
>> ED-1. emoji — A colorful pictograph that can be used inline in text. Internally the representation is either (a) an image or (b) an encoded character.
>> 2 Design Guidelines
>>
>> ...
>> Current practice is for emoji to have a square aspect ratio, deriving from
their origin in Japanese. For interoperability, it is recommended that this
practice be continued with current and future emoji. They will typically have
about the same vertical placement and advance width as CJK ideographs. Since
there have been monochrome emojis, e.g. [Emojione B&W], [Adobe Source Emoji],
Windows 7 [Segoe UI], [Symbola] and first-generation i-mode devices, it does
not make sense to make a colorful appearance mandatory for emojis. All known
implementations of emojis, however, are using square glyphs. (A single
implementation is known to have also used double and triple wide B&W emojis)
Counter proposal
----------------
On the [Unicode mailing list], I have tried to convince the authors of this
proposal, Michael Everson and Garth Wallace, that emoji presentation of chess
pieces would be enough to satisfy the valid use cases they presented, but they
refused to endorse this change (as well as the alternative one to use the same
codepoint for an empty square regardless of its color). I showed that fonts or
higher-level technologies could algorithmically determine the correct field
color for a glyph in a row of eight characters within a chess board diagram
with almost perfect accuracy.
The changes would be made to recently introduced emoji-variation-sequences.txt instead of in StandardizedVariants.txt.
# text-style versus emoji-style variation sequences
2654 FE0E; text style; # WHITE CHESS KING
2654 FE0F; emoji style; # WHITE CHESS KING
2655 FE0E; text style; # WHITE CHESS QUEEN
2655 FE0F; emoji style; # WHITE CHESS QUEEN
2656 FE0E; text style; # WHITE CHESS ROOK
2656 FE0F; emoji style; # WHITE CHESS ROOK
2657 FE0E; text style; # WHITE CHESS BISHOP
2657 FE0F; emoji style; # WHITE CHESS BISHOP
2658 FE0E; text style; # WHITE CHESS KNIGHT
2658 FE0F; emoji style; # WHITE CHESS KNIGHT
2659 FE0E; text style; # WHITE CHESS PAWN
2659 FE0F; emoji style; # WHITE CHESS PAWN
265A FE0E; text style; # BLACK CHESS KING
265A FE0F; emoji style; # BLACK CHESS KING
265B FE0E; text style; # BLACK CHESS QUEEN
265B FE0F; emoji style; # BLACK CHESS QUEEN
265C FE0E; text style; # BLACK CHESS ROOK
265C FE0F; emoji style; # BLACK CHESS ROOK
265D FE0E; text style; # BLACK CHESS BISHOP
265D FE0F; emoji style; # BLACK CHESS BISHOP
265E FE0E; text style; # BLACK CHESS KNIGHT
265E FE0F; emoji style; # BLACK CHESS KNIGHT
265F FE0E; text style; # BLACK CHESS PAWN
265F FE0F; emoji style; # BLACK CHESS PAWN
References
----------
[UTS51]: http://www.unicode.org/reports/tr51/tr51-11.html
[N4793]: http://www.unicode.org/L2/L2017/17077-n4793-chessboard.pdf "N4793 = L2/17-077 'Proposal to add standardized variation sequences for chess notation' by Michael Everson and Garth Wallace (2017-04-01)"
[N4011]: http://www.unicode.org/L2/L2011/11094-n4011-hatching.pdf "N4011 = L2/11-094 'Proposal to add heraldic hatching characters to the UCS' by Michael Everson (2011-04-01)"
[Wikicommons]: https://commons.wikimedia.org/wiki/File:Coa_Illustration_Tinctures_Eng_2.svg "Table of different systems of 'hatching' (i.e. to represent heraldic tinctures using black-and-white) by User:Madboy74"
[My First HDML]: http://cgi.wap2.jp/emoji/ezweb/?act=new_pict "EZweb New Emoji, 519 to 589"
[KDDI]: https://www.au.com/ezfactory/tec/spec/3.html
[KDDI D]: https://www.au.com/ezfactory/tec/spec/pdf/typeD.pdf
[KDDI F]: https://www.au.com/ezfactory/tec/spec/pdf/typeF.pdf
[Openwave]: http://web.archive.org/web/20090515011632/http://developer.openwave.com:80/documentation/xhtml_mp_css_reference/icons.html
[Symbola]: http://users.teilar.gr/~g1951d/
[Emojione B&W]: https://github.com/Ranks/emojione/tree/2.2.7/assets/svg_bw
[Adobe Source Emoji]: https://github.com/adobe-fonts/source-emoji
[Segoe UI]:
[L2/16-021]: http://unicode.org/L2/L2016/16021-game-pieces-emoji.pdf
[L2/16-087]: http://unicode.org/L2/L2016/16087-provisional-value-for-emoji.pdf
[L2/16-088]: http://unicode.org/L2/L2016/16088-chars-for-emoji-provisional.pdf
- https://docs.google.com/spreadsheets/d/1-XLoueD__NZtOPNz4bWl_HwOmwGIt_6aEaWV-l_I0UQ/ (broken)
- https://docs.google.com/spreadsheets/d/1txhi8XYKFMkCaOOFMI2z1tQkNwhzkUN-htofj-oJ1GM/ (original)
- https://docs.google.com/spreadsheets/d/1KQDH9uArJr-8m4UvAEd02ixaX_-wauSwjy9qYCwIOvE/ (extended)
[Unicode mailing list]: http://www.unicode.org/mail-arch/unicode-ml/y2017-m04/0000.html
Date/Time: Sun May 7 18:45:55 CDT 2017
Name: Kent Karlsson
Report Type: Feedback on an Encoding Proposal
Opt Subject: Feedback on L2/17-077
L2/17-077 suggest using variation sequences to support "plain text" printing of chess game boards. While I support the proposal in principle, I have one strong objection. In L2/17-077, it is proposed to use the following for borders: 2581 FE00; Chessboard box drawing; # LOWER ONE EIGHTH BLOCK 258F FE00; Chessboard box drawing; # LEFT ONE EIGHTH BLOCK 2594 FE00; Chessboard box drawing; # UPPER ONE EIGHTH BLOCK 2595 FE00; Chessboard box drawing; # RIGHT ONE EIGHTH BLOCK 2596 FE00; Chessboard box drawing; # QUADRANT LOWER LEFT 2597 FE00; Chessboard box drawing; # QUADRANT LOWER RIGHT 2598 FE00; Chessboard box drawing; # QUADRANT UPPER LEFT 259D FE00; Chessboard box drawing; # QUADRANT UPPER RIGHT However, box drawing cannot be seen as a variation of the given characters, not even by a stretch. I would instead suggest using actual box drawing characters, and "variate" them: 2500 FE00; Chessboard box drawing (top); # BOX DRAWINGS LIGHT HORIZONTAL (U+2500) 2500 FE01; Chessboard box drawing (bottom); # BOX DRAWINGS LIGHT HORIZONTAL (U+2500) 2502 FE00; Chessboard box drawing (left); # BOX DRAWINGS LIGHT VERTICAL (U+2502) 2502 FE01; Chessboard box drawing (right); # BOX DRAWINGS LIGHT VERTICAL (U+2502) 250C FE00; Chessboard box drawing; # BOX DRAWINGS LIGHT DOWN AND RIGHT (U+250C) 2510 FE00; Chessboard box drawing; # BOX DRAWINGS LIGHT DOWN AND LEFT (U+2510) 2514 FE00; Chessboard box drawing; # BOX DRAWINGS LIGHT UP AND RIGHT (U+2514) 2518 FE00; Chessboard box drawing; # BOX DRAWINGS LIGHT UP AND LEFT (U+2518) And for double borders: 2550 FE00; Chessboard box drawing (top); # BOX DRAWINGS DOUBLE HORIZONTAL (U+2550) 2550 FE01; Chessboard box drawing (bottom); # BOX DRAWINGS DOUBLE HORIZONTAL (U+2550) 2551 FE00; Chessboard box drawing (left); # BOX DRAWINGS DOUBLE VERTICAL (U+2551) 2551 FE01; Chessboard box drawing (right); # BOX DRAWINGS DOUBLE VERTICAL (U+2551) 2554 FE00; Chessboard box drawing; # BOX DRAWINGS DOUBLE DOWN AND RIGHT (U+2554) 2557 FE00; Chessboard box drawing; # BOX DRAWINGS DOUBLE DOWN AND LEFT (U+2557) 255A FE00; Chessboard box drawing; # BOX DRAWINGS DOUBLE UP AND RIGHT (U+255A) 255D FE00; Chessboard box drawing; # BOX DRAWINGS DOUBLE UP AND LEFT (U+255D) Note the use of both FE00 and FE01 to distinguish top/bottom and left/right. (end of this feedback)
Date/Time: Sun May 7 18:53:24 CDT 2017
Name: Kent Karlsson
Report Type: Feedback on an Encoding Proposal
Opt Subject: A "see also" for L2/17-078
In L2/17-078 an updated ordering for Hangul is proposed. See also CLDR ticket http://unicode.org/cldr/trac/ticket/10246 and its attachment, giving a CLDR collation tailoring for Hangul.
Date/Time: Thu Apr 27 16:59:58 CDT 2017
Name: Markus Scherer
Report Type: Error Report
Opt Subject: UTS #18 Full Properties with string values
http://www.unicode.org/reports/tr18/#Full_Properties includes ten properties with string values that seem questionable to me as a requirement for regex patterns: - Lowercase_Mapping & Simple_Lowercase_Mapping - similar for title/upper/case-folding - Bidi_Mirroring_Glyph & Bidi_Paired_Bracket Unicode libraries commonly implement case mapping of code points and strings, and regex matchers commonly implement a case-insensitive mode, but these properties seem unusual for regex patterns, that is, for selecting characters to match. These properties have string values (some limited to single code points) which are not very useful for selection/matching. In addition, the full case mapping properties are language-dependent and context-sensitive (Case_Folding has a Turkic option), and it is therefore unclear what they mean in regex patterns. I suggest to remove these ten properties from RL2.7 Full Properties. If not, then please provide syntax examples for a subset that covers all cases (e.g., Lowercase_Mapping, Case_Folding, Bidi_Mirroring_Glyph) and define the semantics for those properties that also need language/Turkic/context to be fully functional. Consider creating a new section beyond Full Properties, maybe "Extended Properties" (or "unusual" or...). Note that "full" is already somewhat misleading. There are several UCD properties that are not listed here, for example most of the Unihan properties. Unicode also defines properties outside the UCD, such as the emoji properties. Note also that the Full Properties are listed with their UCD PropertyAliases, e.g., "Lowercase_Mapping", but section 1.2.3 Other Properties shows examples like "[:toLowercase=a:]". It is unclear what the preferred syntax would be. I do realize that there are other string-valued Full Properties (e.g., Name & Block); those do make some sense to me for regex patterns.
Date/Time: Thu Apr 27 17:06:44 CDT 2017
Name: Markus Scherer
Report Type: Error Report
Opt Subject: UTS #18 vertical orientation
http://www.unicode.org/reports/tr18/ section 1.2.3 Other Properties has a bullet for "vertical orientation from [UTR50]" UTR #50 is becoming UAX #50, and vo=Vertical_Orientation is a UCD property in Unicode 10. I suggest changing this bullet to "Vertical_Orientation from [UAX50]".
Date/Time: Wed Apr 12 15:07:40 CDT 2017
Name: David Corbett
Report Type: Error Report
Opt Subject: Inadequate description of SignWriting
The two-page description of SignWriting in “The Unicode Standard”, version 9.0, chapter 21, is inadequate. It gives the gist of the encoding model, i.e. rotations and fills, but not in enough detail to do anything with. For example, according to L2/12-321 (the proposal) <U+1D9FF SIGNWRITING HEAD, U+1DA16 SIGNWRITING EYES CLOSED, U+1DA9B SIGNWRITING FILL MODIFIER-2> is a head with the right eye closed but there is no way to know that by reading the standard. Also according L2/12-321, headshapes cannot take U+1DAA4 SIGNWRITING ROTATION MODIFIER-5, but again, the standard does not say so. I suggest creating a Unicode Technical Standard based on L2/12-321 plus an exhaustive list of valid SignWriting sequences and their descriptions.
Date/Time: Wed Apr 12 18:53:25 CDT 2017
Name: Jaemin Chung
Report Type: Other Question, Problem, or Feedback
Opt Subject: Proposal to add an informative note to U+332C
I propose to add the following informative note to U+332C ㌬. • This is an unused character; it is a mistake for the Thai currency bahts (バーツ in Japanese). For details, please see the following post written by Dr. Ken Lunde: https://blogs.adobe.com/CCJKType/2016/03/bahts-is-parts.html
Date/Time: Tue Apr 25 06:49:44 CDT 2017
Name: Eiso Chan
Report Type: Public Review Issue
Opt Subject: U+2D544 & Adobe-Japan1 CID+13834
Note: This feedback added here at request of IVD Registrar, for UTC discussion.
U+2D544 in CJK Ext F and Adobe-Japan1 CID+13834 (aka <U+5C0F,U+E0102>) are the same. Pls add these to PRI 349 like CID+14187 & CID+14226.