Comments on Public Review Issues
(January 24 - April 26, 2018)

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.

Issue Name Feedback Link
377 Proposed Update UAX #42, Unicode Character Database in XML (feedback) No feedback to date
376 Proposed Update UAX #14, Unicode Line Breaking Algorithm (feedback)
375 Proposed Update UTS #46 Unicode IDNA Compatibility Processing (feedback)
374 Proposed Update UTS #39 Unicode Security Mechanisms (feedback)
373 Proposed Update UAX #31 Unicode Identifier and Pattern Syntax (feedback) No feedback to date
372 Unicode 11.0.0 Beta (feedback)
371 Proposed Update UAX #41, Common References for Unicode Standard Annexes (feedback) No feedback to date
370 Proposed Update UAX #15, Unicode Normalization Forms (feedback)
369 Proposed Update UAX #50, Unicode Vertical Text Layout (feedback) No feedback to date
368 Proposed Update UAX #9, Unicode Bidirectional Algorithm (feedback)
362 Proposed Update UAX #45 U-source Ideographs (feedback) No new feedback since Jan 2018
361 Proposed Update UAX #38 Unicode Han Database (Unihan) (feedback)
360 Proposed Update UAX #11, East Asian Width (feedback) No feedback to date
359 Proposed Draft UTR #53, Unicode Arabic Mark Rendering (feedback) No new feedback since Jan 2018
358 Proposed Update UTS #10, Unicode Collation Algorithm (feedback) No feedback to date
357 Proposed Update UAX #44, Unicode Character Database (feedback)
356 Proposed Update UTS #51, Unicode Emoji (feedback)
355 Proposed Update UAX #29 Unicode Text Segmentation (feedback)

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 


Feedback to UTC / Encoding Proposals

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
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
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.


Utilizing the old emoji would cut this number down to three codepoints, or
five with skin tones:


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
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
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

Feedback on UTRs / UAXes

Error Reports

Other Reports

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


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: