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: Mon Apr 28 23:15:54 CDT 2014
Name: Emmanuel Vallois
Report Type: Public Review Issue
Opt Subject: [PRI #266] Some little things overlooked?
There's an error in the third bullet in the description of kDefaultSortKey. “U+20000 through U+2F7FF are mapped to 0x06C00 through 0x1F4FF; that is, 0x19400 is subtracted from the Unicode Scalar Value.” 0x2F7FF - 0x19400 = 0x163FF, thus should be changed to “U+20000 through U+2F7FF are mapped to 0x06C00 through 0x163FF; that is, 0x19400 is subtracted from the Unicode Scalar Value.” Concerning the data, the diff file shows: kSpecializedSemanticVariant 534C <undefined> -> 'U+2099C' kSpecializedSemanticVariant 2098C <undefined> -> 'U+2099C' kSpecializedSemanticVariant 2099C <undefined> -> 'U+5E4C U+2098C' I think that the first line is erroneous and is about 5E4C and not 534C (a typo?), as 5E4C is indeed similar to 2099C, even for a non-specialist, whereas 534C seems unrelated. kSemanticVariant 534C <undefined> -> 'U+2098C<kHanYu' kSemanticVariant 2098C <undefined> -> 'U+5E4C<kHanYu:T' Here again, I think first line should refer to 5E4C rather than 534C.
Date/Time: Wed Apr 30 18:03:47 CDT 2014
Name: Markus Scherer
Report Type: Error Report
Opt Subject: UAX #38 Unihan kDefaultSortKey
The code point portion of kDefaultSortKey (see http://www.unicode.org/reports/tr38/#DatabaseDesign) sorts the BMP compatibility characters after all of the Extensions. UCA (http://www.unicode.org/reports/tr10/#Implicit_Weights) sorts them between the original Unihan block and Extension A. Is this a bug in UAX #38? I realize that the overall order of kDefaultSortKey is different from UCA implicit Han primaries, but it seems like the code point portion should be parallel to UCA implicit primaries, given how small the difference is.