L2/17-018

Comments on Public Review Issues
(November 7, 2016 - January 26, 2017)

The sections below contain links to permanent feedback documents for the open Public Review Issues as well as other public feedback as of January 26, 2017, since the previous cumulative document was issued prior to UTC #149 (November 2016). Some items in the Table of Contents do not have feedback here.

Contents:

The links below go directly to open PRIs and to feedback documents for them, as of January 18, 2017.

Issue Name Feedback Link
344 New Unicode Character Property EquivalentUnifiedIdeograph (feedback)
343 Proposed Update UTR #51, Unicode Emoji (Version 5.0) (feedback)
342 Proposed Update UAX #50 Unicode Vertical Text Layout (feedback) no feedback to date
341 Proposed Update UAX #29 Unicode Text Segmentation (feedback)
340 Proposed Update UAX #9 Unicode Bidirectional Algorithm (feedback)
337 Proposed Update UTS #37, Unicode Ideographic Variation Database (feedback) no feedback to date
336 Proposed Update UAX #41, Common References for Unicode Standard Annexes (feedback) no feedback to date
335 Proposed Update UAX #14, Unicode Line Breaking Algorithm (feedback)
334 Proposed Update UTS #39, Unicode Security Mechanisms (feedback)
333 Proposed Update UAX #31, Unicode Identifier and Pattern Syntax (feedback)
332 Proposed Update UTS #10, Unicode Collation Algorithm (feedback)
329 Proposed Update UAX #44, Unicode Character Database (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/15-241  L2/17-011 

 


Feedback to UTC / Encoding Proposals

Date/Time: Sun Dec 25 08:29:04 CST 2016
Name: S Barmeier
Report Type: Error Report (Feedback on L2/15-241)
Opt Subject: Description of U+A7AF LATIN LETTER SMALL CAPITAL Q

Dear Unicode list,

The character U+A7AF LATIN LETTER SMALL CAPITAL Q of proposal L2/15-241 
has been accepted for inclusion in the Unicode standard, and is listed 
in "Additional repertoire for ISO/IEC 10646:2016 (5th ed.) Amendment 1.2" 
(http://www.unicode.org/L2/L2016/16381-n4778r-pdam1-2-charts.pdf).

However, it is listed under "Letter for representation of morpheme in 
Japanese", which appears to be a typo for "Letter for representation of 
phoneme in Japanese". (The original proposal does not contain the word "morpheme".)

https://en.wikipedia.org/wiki/Morpheme
https://en.wikipedia.org/wiki/Phoneme

Regards,
Severin Barmeier

Date/Time: Tue Jan 17 20:59:50 CST 2017
Name: John Cowan
Report Type: Feedback on an Encoding Proposal
Opt Subject: (L2/17-011)
Summary of options for redhead emoji

I would point out that Malcolm X had type 4 skin but red hair. According to
Wikipedia, he inherited the red hair from his Scots grandfather. In addition,
African Americans with dyed red hair are easily found: Google for [african
american red hair]. This makes solution 2 (associate red hair with pale skin)
unworkable.

Date/Time: Thu Jan 26 02:20:50 CST 2017
Name: Christoph Päper
Report Type: Other Question, Problem, or Feedback
Opt Subject: L2/16-337r ESC Process

The document does not specify the visibility for proposals in Stage 6
_Rejected_. Since it had reached Stage 2 before, the proposal will still be
publicly available in the document register, but will certainly be removed
from candidate charts (Stage 3) and beta data files (Stage 4). No emoji can
ever advance from Stage 5 to 6, so perhaps it should be called “Stage 1b” or
“Stage 0” instead.

There currently is no (public) document which lists emoji candidates that
failed to advance further or reasons for why a particular proposal was
rejected. If such a document was available at
<http://www.unicode.org/emoji/charts/> it could serve as a reference to
improve the quality of new proposals submitted to the ESC and discourage
futile ones. One could also point people to it if asked “why is there no […]
emoji?” which is a question raised frequently – and really means “I wish there
was a […] emoji!” in most cases.

Feedback on UTRs / UAXes

Date/Time: Thu Jan 5 10:29:43 CST 2017
Name: Alastair Houghton
Report Type: Error Report (UTS #46)
Opt Subject: IdnaTest.txt contains incorrect test cases

The test vectors for UTS #46, which can be found in
http://www.unicode.org/Public/idna/9.0.0/IdnaTest.txt appear to have a few
errors.

For instance, line 74:

 B;	0à.\u05D0;	;	xn--0-sfa.xn--4db	#	0à.א

which should fail [B1] because the first character has Bidi property EN, not
L, R or AL, and line 93:

 B;	àˇ.\u05D0;	;	xn--0ca88g.xn--4db	#	àˇ.א

which should fail [B6] because “ˇ” has Bidi property ON, not L, EN or NSM.

This is quite a common problem in the file.

(I've already mentioned this on the Unicode mailing list and was asked by Mark
Davis to report it here.)

Error Reports


Other Reports

Date/Time: Wed Jan 18 20:03:59 CST 2017
Name: Eric Muller
Report Type: Error Report
Opt Subject: Text for Devanagari RA + vocalic liquids

The current text, TUS 9.0, top of p 460

The phonological sequence /r vocalic_r/ can graphically appear either as 
<myriad>RA<sub>l</sub></myriad> with a vowel sign 
for the vocalic_r, or as <smcp>VOCALIC R</smcp> with a superscript 
mark <myriad>RA<sub>sup</sub></myriad>.

I suggest to:

- add "<myriad>VOWEL SIGN VOCALIC R<sub>vs</sub></myriad>" 
	before the comma (or just after the "sign" that precedes it),

- replace "<smcp>VOCALIC R</smcp>" by "<myriad>LETTER 
	VOCALIC R<sub>l</sub></myriad>"Eric.

Date/Time: Sat Jan 21 17:12:39 CST 2017
Name: Karl Williamson
Report Type: Other Question, Problem, or Feedback
Opt Subject: Best practices for replacing UTF-8 overlongs

A little over a month ago, I wrote a question to the unicode mailing list concerning 
the current rules in TUS for handling overlongs.  Its message id was 
<20083c6b-c861-b197-5fdb-d091daaeb517@khwilliamson.com>.  In short, I believe 
the best practices are wrong.  This started a thread of comments, but no official 
explanation from any one in Unicode as to the rationale of why it is the way it is. 
Ken Whistler explicitly declined to defend the current text.  And I found out that 
implementations, like ICU, do it the way I think it should be done.

I would like the text changed to promote the ICU implementation as the best practice.