The sections below contain links to permanent feedback documents for the open Public Review Issues as well as other public feedback as of April 26, 2018, since the previous cumulative document was issued prior to UTC #154 (January 2018). 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 April 25, 2018.
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/16-311R
L2/17-242R
L2/17-435
L2/18-056
L2/18-090
L2/18-091
L2/18-141
Date/Time: Tue Jan 23 17:15:00 CST 2018
Name: Eduardo Marín Silva
Report Type: Feedback on an Encoding Proposal
Opt Subject: Stylized digits for atari st compatibility (L2/17-435)
I'm one of the coauthors of the original proposal L2/17-435 for semi- graphics of old computers. I have a piece of feedback that occured to me way to late to be included in the original proposal. And that is the stylized seven segment digits look very different than their normal counterparts and are therefore not elligible for SVs so, here I propose encoding them atomically in a new block called Number Forms Extended. It should have three rows just like its cousin.
Date/Time: Fri Jan 26 13:54:25 CST 2018
Name: Eduardo Marín Silva
Report Type: Feedback on an Encoding Proposal
Opt Subject: Code point assignment of the new creative commons characters
L2/17-242R
In my opinion, the CIRCLED HUMAN FIGURE should occupy 2B75, while the CIRCLED DOLLAR SIGN WITH OVERLAID BACKSLASH should occupy 1F16F, that way it is more in line with the semantics of the names of the blocks. Each of the blocks should have the appropiate annotations so that users know where to look for the complete set of symbols.
Date/Time: Wed Jan 31 12:24:04 CST 2018
Name: Eduardo Marín Silva
Report Type: Feedback on an Encoding Proposal
Opt Subject: Name of Circled Counterclockwise arrow (L2/17-242R)
I suggest changing the name of this character to: CIRCLED ANTICLOCKWISE GAPPED CIRCLE ARROW. This name better describes the glyph in my view and is more in line with other names of other arrows. The character that I'm talking about was recently approved in UTC 154, they are from this document http://www.unicode.org/L2/L2017/17242r-creative-commons.pdf
Date/Time: Sat Feb 10 14:53:38 CST 2018
Name: (anonymous)
Report Type: Feedback on an Encoding Proposal
Opt Subject: Proposed unification of Creative Commons signs (L2/17-242R)
The were some recently approved signs for use to indicate Creative Common licenses. One of those was unified with the sign CIRCLED EQUALS, used for mathematics. In a similar rationale I propose unyfing the CIRCLED ZERO WITH SLASH, with CIRCLED DIGIT ZERO (24EA), and distinguishing them through a variation sequence, similar to the one used for the regular DIGIT ZERO.
Date/Time: Tue Feb 20 13:26:07 CST 2018
Name: Anshuman Pandey
Report Type: Error Report
Opt Subject: Misspelling of name of U+10D23 in names list of
L2/16-311R
The Unibook names list in L2/16-311R "Revised proposal to encode Hanifi Rohingya in Unicode" contains a misspelling. The name for U+10D23 is specified correctly as HANIFI ROHINGYA NA KHONNA throughout the text of the proposal and in the character data. However, in the names list (p.20), 'KHONNA' is spelled incorrectly as *'KHANNA'. As the author of the proposal, I apologize for the error and any inconvenience this may have caused. I have communicated with Ken Whistler, Michel Suignard, and Laurentiu Iancu regarding the issue.
Date/Time: Fri Mar 23 19:13:59 CDT 2018
Name: Charlotte Buff
Report Type: Feedback on an Encoding Proposal
Opt Subject: Feedback on Codepoints for Creative Commons Symbols (L2/18-056)
As documented in L2/18-056 ( https://unicode.org/L2/L2018/18056-future-adds.pdf), the six Creative Commons symbols are tentatively allocated to two separate blocks: CIRCLED ZERO WITH SLASH, CIRCLED CC, CIRCLED C WITH OVERLAID BACKSLASH, and CIRCLED HUMAN FIGURE are in Enclosed Alphanumeric Supplement; CIRCLED COUNTERCLOCKWISE ARROW and CIRCLED DOLLAR SIGN WITH OVERLAID BACKSLASH are in Miscellaneous Symbols and Arrows. I believe that two of these characters should switch places: CIRCLED DOLLAR SIGN WITH OVERLAID BACKSLASH should be in Enclosed Alphanumeric Supplement, and CIRCLED HUMAN FIGURE should be in Miscellaneous Symbols and Arrows. While it can be argued that a dollar sign may not really be an alphanumeric symbol, I think it is pretty uncontroversial to say that a human figure definitely is not alphanumeric. Therefore, CIRCLED HUMAN FIGURE should not be encoded in a block that is specifically meant for alphanumeric characters.
Date/Time: Fri Apr 13 13:08:39 CDT 2018
Name: David Corbett
Report Type: Feedback on an Encoding Proposal
Opt Subject: Feedback on the tachograph bed symbol (L2/18-090)
L2/18-090 “On the encoding of tachograph symbols” mentions a bed symbol used to represent a break from work. The top picture on page 9 of the proposal shows that there are actually two bed symbols, labeled “PA” and “RU” (i.e. “Pausenzeiten” and “Ruhezeiten”). The proposal should take that into account.
Date/Time: Sat Apr 14 05:07:01 CDT 2018
Name: Charlotte Buff
Report Type: Feedback on an Encoding Proposal
Opt Subject: Feedback on
L2/18-091: ZWJ Sequences for Couples Holding Hands
Proposal L2/18-091 (“Emoji Proposal for SITTING PERSON, STANDING PERSON and KNEELING PERSON”) mentions the possibility of using the proposed PERSON STANDING character as part of ZWJ sequences for couples holding hands. I want to advise against this idea for a variety of reasons. Please note that this is solely about that specific mechanism; I have no opinion either way on the actual characters suggested in that document. Firstly, the new character isn’t really necessary for this purpose. The defining quality of 👫, 👬, and 👭 isn’t their upright stance, but the fact that they’re couples. It doesn’t matter whether the people are depicted as standing or sitting or lying down as long as their hands are touching. In my opinion, the existing characters MAN, WOMAN, and ADULT should be more than sufficient for producing these couples. The fallback display doesn’t have to be an exact match to how the emoji look when ZWJ’d. For example, the family sequences commonly show the full upper bodies of all members, even though the individual characters they are made up of usually only consist of the head. Using the existing characters also makes semantic sense: Two people are a couple; two people and a child are a family (🧑🧑 → 🧑🧑🧒). There is partial precedence for this kind of sequence. On Microsoft Windows, zero-width-joining two instances of MAN and/or WOMAN together produces a standing couple (👨👨, 👨👩, 👩👨, 👩👩). This is part of Microsoft’s comprehensive support for family sequences; joining a child to these couples will superimpose the child glyph on the parents. While these sequences use a different design than the actual couple characters – in particular, they aren’t actually holding hands – it is pretty clear just from looking at them that they are meant to be in some form of relationship, which is the one crucial aspect that needs to be represented. This existing ligating behaviour could be refined to substitute a glyph with touching hands when no children are present. There is also a pragmatic reason for preferring the existing emoji: Using PERSON STANDING would simply require too many characters. PERSON STANDING has no gender, so it would have to be modified with ♀️ and ♂️ to allow for the same gender range as the atomicly encoded couples. A man and a woman holding hands would require a total of nine codepoints using this approach, more than any emoji sequence that exists today. And this doesn’t even account for the two optional skin tone modifiers, which were the primary motivation behind the original proposal in the first place. PERSON STANDING + ZWJ + MALE SIGN + VS16 + ZWJ + PERSON STANDING + ZWJ + FEMALE SIGN + VS16 Utilizing the old emoji would cut this number down to three codepoints, or five with skin tones: MAN + ZWJ + WOMAN
Date/Time: Mon Apr 30 07:28:03 CDT 2018
Name: William Overington
Report Type: Feedback on an Encoding Proposal
Opt Subject: Some comments on
L2/18-141 Emoji Colors
It seems to me that the existing red filled circle and the existing blue filled circle are best avoided in this context. The colours of them as displayed in the 18141-emoji-colors.pdf document are not compatible with the calculations of pink and light blue that are in the same document. I consider that it would be better to encode an emoji red colour operator and an emoji blue colour operator within a collection of emoji colour operator characters. This would avoid any issues of whether the display of one of the existing emoji colour-filled circles is intended in any particular context to be regarded as a display of that character as such or as an emoji colour operator. I am thinking that a new shape - maybe something like a horizontally flipped hysteresis loop from the physics of magnetism, then filled with colour - would be better than using filled circles for what are emoji colour operators, and encoding sixteen emoji colour operators to start, and not using the existing colour-filled circles as emoji colour operators. Here is a design that I have produced for a suggested emoji colour operator, here shown for an emoji blue colour operator. The angle of the slope is 15 degrees from vertical. [As I cannot add an image into the contact form I am sending two copies of the image, at different sizes, by email to human4@unicode.org and also to Rick in the hope that this bracketed paragraph will be replaced by either or both images in the web page of comments if these comments are accepted for inclusion therein.] It seems to me that the RGB values of the emoji colour operators need to be defined in The Unicode Standard. Otherwise various colour variations could be used by various font designers and a muddle would ensue. Although precisely defining colours in The Unicode Standard would be a new feature I consider it better to introduce the new feature rather than there be a muddle in application of the emoji colour operators. I suggest that sixteen emoji colour operators be defined at first with space reserved to add more emoji colour operators. I suggest the following sixteen colours. Black, Brown, Red, Orange, Yellow, Green, Blue, Magenta, Grey, White, Cyan, Pink, Dark Grey, Light Grey, Dark Green, Sky Blue. The document contains the following claim. > > All the 16,777,216 RGB colors cannot be encoded. Well, how about encoding EMOJI COLOUR OPERATOR BASE CHARACTER and then having a TAG NUMBER SIGN and then another six tag characters to express the hexadecimal encoding of an RGB colour. Certainly a new way of rendering colour would need to be added to OpenType colour font technology, but the RGB colours could all be encoded into Unicode quite straightforwardly. William Overington Monday 30 April 2018
Date/Time: Wed Jan 24 07:48:18 CST 2018
Name: Sultan M Saeed
Report Type: Public Review Issue
Opt Subject:
I propose to integrate the Arabic language OSA (Unicode label) into the new Unicode keyboard, as a digitally deprived language, and its revival is among the goals of the Union, so we hope that its characters will be included in the new optimization in the keyboard layouts allowing it to be used in various scripts And digital devices, and we will provide the required features of drawings, layouts and digital lines in various formats for inclusion in the current Unicode proposal.
Date/Time: Wed Jan 24 08:05:19 CST 2018
Name: Ludovic Oger
Report Type: Other Question, Problem, or Feedback
Opt Subject: Request to extend International Phonetic Alphabet
Hello, I have a request about the International Phonetic Alphabet (IPA). Most of symbols of IPA have their own character but there's issues with a few. For example, the greek letter theta (θ, U+03B8) represent the sound made by "th" in "the" in English language. While others "fake" greek letters are in the IPA extension block of Unicode: 'fake' gamma is U+0263, 'fake' phi is U+0278. You could tell me that it's not a big deal, but... this is a big deal in braille automatic transcription: Greek letters have theirs own braille coding in English or French braille codes but IPA braille coding is international and different. I created an IPA/braille table (https://github.com/liblouis/liblouis/blob/v3.4.0/tables/IPA.utb) for a braille software and the issue with this few symbols are awkward to transcribe phonetics. Is it possible to extend the IPA extension block to match the whole IPA? Best regards, Ludovic Oger
Date/Time: Tue Apr 10 14:50:51 CDT 2018
Name: Ken Lunde
Report Type: Other Question, Problem, or Feedback
Opt Subject: U+32FF SQUARE ERA NAME XXXXXX status
With regard to U+32FF, which was reserved during UTC #154 for the two- ideograph square ligature that represents the forthcoming new Japan era name that is scheduled to start on 2019-05-01 per a request from Japan, the following articles from a month ago strongly suggest that squeezing it into Unicode Version 12.0, which is already on an accelerated schedule, is clearly at risk: https://www.japantimes.co.jp/news/2018/03/07/national/japan-name-next-era-february-2019-ceremony-celebrating-emperors-enthronement/ https://www.nippon.com/en/genre/politics/l10797/