Accumulated Feedback on PRI #206

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.

Date/Time: Sun Sep 25 13:04:10 CDT 2011
Name: Karl Williamson
Report Type: Public Review Issue
Opt Subject: PropertyValueAliases.txt inconsistencies

PropetyValueAliases.txt is supposed to be constructed so that the
first field is the property name; the 2nd the value's abbreviated
name; the 3rd the long name; and any additional names are in trailing
fields.  Four entries in the file are anomalous, and I'm requesting
that these be changed to the same as the other file entries.  The
entries in question are:

dt ; Font      ; font
dt ; None      ; none
dt ; Sub       ; sub
dt ; Wide      ; wide

What each of these says is that the long name is the short name lower-
cased.  Thus the long name comes out as less formal than the short
name.  In no other cases are long names less formal than their short
names.  I believe that what was intended was something like other
entries for the dt property:

dt ; Can       ; Canonical                        ; can

I would like the 4 entries to be changed to:
dt ; Font      ; Font                             ; font
dt ; None      ; None                             ; none
dt ; Sub       ; Sub                              ; sub
dt ; Wide      ; Wide                             ; wide

to correspond with the other entries in dt.

Since Unicode property value matching rules call for case to be
ignored, I don't understand, anyway, why there is an extra alias for
these that is just the lower-cased short name.  Perhaps this extra
alias should be omitted.

Date/Time: Sun Sep 25 14:08:42 CDT 2011
Name: Karl Williamson
Report Type: Public Review Issue
Opt Subject: Inconsistent @missings in UCD .txt files

Some files use the abbreviated property value name for their data, and
some use the long one.  It would be nice if this were consistent, but
I suppose that it's too late to change these.  The most annoying is
that ScriptExtensions.txt uses the short name, while Scripts.txt uses
the long, and ScriptExtensions is not stand-alone, so code that reads
them both has to convert.  Since this is a provisional property, it
may not be too late to change this.  I ask for this to be considered.

But my major request is that the @missings lines in a file use the
same style (abbreviated or long) as the rest of the lines in the file
for a given property.  Unicode hasn't formally specified the format of
the lines in the UCD .txt files that give the default value for code
points not explicitly mentioned (at least last time I looked it
hadn't), yet these are specified as to be machine-readable.  So, I've
assumed that the format is stable, and programmed reading them based
on the existing paradigm, but I would think that it would be possible
to change to the other style in these lines.

For example, there is an annoying inconsistency in the
DerivedNormalizationProps.txt file. The value for code points that are
explicitly listed are based on the abbreviated property value alias,
'N' and 'M', but the missing defaults are listed as the long property

# @missing: 0000..10FFFF; NFD_QC; Yes
# @missing: 0000..10FFFF; NFC_QC; Yes
# @missing: 0000..10FFFF; NFKD_QC; Yes
# @missing: 0000..10FFFF; NFKC_QC; Yes

I've had to program around this inconsistency, as has Asmus Freytag.
The problem is that I'm writing code to expose the UCD db to Perl
programs for the next Perl version.  I would rather they not have to
program around this inconsistency, as well.  And it seems like the
best place to fix it is at the source.  I am requesting that Unicode
change these lines to be:

# @missing: 0000..10FFFF; NFD_QC; Y
# @missing: 0000..10FFFF; NFC_QC; Y
# @missing: 0000..10FFFF; NFKD_QC; Y
# @missing: 0000..10FFFF; NFKC_QC; Y

There are other files where this is true as well, namely 
HangulSyllableType-6.1.0d11.txt:# @missing: 0000..10FFFF; Not_Applicable
extracted/DerivedBidiClass-6.1.0d12.txt:# @missing: 0000..10FFFF; Left_To_Right
extracted/DerivedCombiningClass-6.1.0d12.txt:# @missing: 0000..10FFFF; Not_Reordered
extracted/DerivedEastAsianWidth-6.1.0d12.txt:# @missing: 0000..10FFFF; Neutral
extracted/DerivedJoiningType-6.1.0d12.txt:# @missing: 0000..10FFFF; Non_Joining
extracted/DerivedLineBreak-6.1.0d12.txt:# @missing: 0000..10FFFF; Unknown

It would be nice if these were made consistent with the rest of the
data in their respective files

Date/Time: Tue Oct 4 00:24:51 CDT 2011
Name: Shriramana Sharma
Report Type: Public Review Issue
Opt Subject: Feedback on PRI 206 Unicode 6.1 beta

In the Tifinagh beta chart from 
the character 2D7F Tifinagh Consonant Joiner still has the annotation: "shape shown is 
arbitrary and is not visibly rendered".

This is not entirely true. The recent document L2/11-112, based on which the glyph of 
this character 2D7F has been changed from a boxed TFNCJ to six dots in a dotted box, 
specifically says that it is desired to display the six dots when a proper biconsonant 
glyph is not available.

It is hence recommended that the above annotation be changed to read:

"* shape shown is arbitrary;
 * the six dots are recommended for fallback use if a biconsonant glyph is not available"

or something like that.

Date/Time: Sat Oct 8 00:44:35 CDT 2011
Name: Peter Constable
Report Type: Public Review Issue
Opt Subject: Beta review: Bidi category of 1F48C

In TUS6.0 and the beta, the bidi category of 1F48C is set to L. It should be ON, 
like all the other symbols in that block. Ken Whistler indicated that the case was a 
script used in drafting data files detecting "letter" in the character name, LOVE LETTER.

Date/Time: Sat Oct 8 00:46:10 CDT 2011
Name: Peter Constable
Report Type: Public Review Issue
Opt Subject: Beta review: Bidi category of 1F48C

Addendum: provided by Ken Whistler:

BTW, when you report that one, there is another with the exact
same problem:


which is also bc=L, instead of the expected bc=ON.



which *did* get corrected, and is the expected bc=ON.

Date/Time: Tue Oct 25 17:56:09 CDT 2011
Name: Markus Scherer
Report Type: Public Review Issue
Opt Subject: Unicode 6.1 DerivedBidiClass.txt bug

# DerivedBidiClass-6.1.0.txt
# Date: 2011-09-16, 21:06:13 GMT [MD]

has moved U+1EE00  - U+1EEFF from default-R to default-AL.
The problem is that in the comments U+1EEFF is listed as both AL and R. Please 
change the comments so that U+1EF00 is the first remaining default-R code point.

#     [\u0590-\u05FF \u07C0-\u089F \uFB1D-\uFB4F \U00010800-\U00010FFF \U0001E800-\u0001EDFF \U0001EEFF-\U0001EFFF]
#     [\u0590-\u05FF \u07C0-\u089F \uFB1D-\uFB4F \U00010800-\U00010FFF \U0001E800-\u0001EDFF \U0001EF00-\U0001EFFF]

and change
#                        U+1EEFF - U+1EFFF
#                        U+1EF00 - U+1EFFF

The actual data looks correct.