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: Tue Oct 21 01:01:22 PT 2025
ReportID: ID20251021010122
Name: Eiso Chan
Report Type: Report Error in Publication/Data
Opt Subject: UTC-00733
The current information is below. UTC-00733;Variant;U+81A5;130.11;;⿰未⿱成肉;kCheungBauerIndex 453.09;;; But, this one should be mapped to U+31F1A 𱼚 in CJK Ext. H.
Date/Time: Wed Nov 12 19:50:42 PT 2025
ReportID: ID20251112195042
Name: Eiso Chan
Report Type: Report Error in Publication/Data
Opt Subject: G-Source references for U+3A36 㨶 and U+6440 摀
As what I wrote for WS2024-01574 on the IRG WS2024 ORT (https://hc.jsecs.org/irg/ws2024/app/?id=01574). I suggest update the G-Source references as below and the G glyphs should be kept as-is. U+3A36 kIRG_GSource GKX-0450.19 U+6440 kIRG_GSource G5-4B63 The kGB5 property value under U+3A36 㨶 should be removed and move the corresponding value to U+6440 摀 U+6440 kGB5 4367
Date/Time: Wed Nov 19 09:31:17 PT 2025
ReportID: ID20251119093117
Name: Ken Lunde
Report Type: Report Error in Publication/Data
Opt Subject: kTotalStrokes property value changes
The informative kTotalStrokes property values of the following two ideographs, which are also used as components of other ideographs, should be changed as follows to conform to IRG stroke-counting conventions: U+4E9F kTotalStrokes 9 (currently 8) U+268DE kTotalStrokes 7 (currently 6)
Date/Time: Tue Dec 09 08:59:46 PT 2025
ReportID: ID20251209085946
Name: Ken Lunde
Report Type: PRI Feedback
Opt Subject: PRI 534
I received a report that five kMandarin property values in the Extension I block that were added in Unicode Version 17.0 are incorrect, which I was able to trace to a one-off error on pp 2 and 3 of document L2/25-029 in which the CLDR-TC responded to proposed kMandarin property values in document L2/23-209. What caused this issue is that the code point in the referenced URL in the eighth (and final) column is one higher than the code point in the first column, and the glyph in the second column is for the character that is one code point higher than that in the first column. The CLDR-TC confirmed the errors and the following corrections on 2025-12-08: U+2EC3D kMandarin yuè (currently lǎn) U+2EC3E kMandarin lǎn (currently qiè) U+2EC3F kMandarin qiè (currently xíng) U+2EC41 kMandarin jìn (currently yǔ) U+2EC52 kMandarin niǎo (currently yàn)
Date/Time: Tue Dec 23 12:52:37 PT 2025
ReportID: ID20251223125237
Name: Llinos Evans
Report Type: PRI Feedback
Opt Subject: kTang information
The data in kTang does not seem sufficient; The Tang dynasty pronunciation(s) of this ideograph, derived from or consistent with T’ang Poetic Vocabulary by Hugh M. Stimson, Far Eastern Publications, Yale University 1976. An asterisk indicates that the word or morpheme represented in toto or in part by the given ideograph with the given reading occurs more than four times in the seven hundred poems covered. Specifically, it does not denote where the pronunciations come from in that text. Are they Pulleyblank/Karlgren/etc reconstructions? Is it based on the Qieyun, Guangyun, etc? It would be extremely handy if this were noted if only to make it a little more comprehensive, otherwise it isn't very useful to an outsider like myself. I did try to track down the book but the only listing I could find is £100 and it isn't on any shadow libraries. Mind lending a hand?
Feedback above this line has already been reviewed during UTC #186 in January, 2026.
Date/Time: Wed Jan 21 21:55:18 PT 2026
ReportID: ID20260121215518
Name: Maximilien Mellen
Report Type: PRI Feedback
Opt Subject: Error in kFourCornerCode for U+71AF (熯)
I would like to report what I believe is an error in the Unihan database property kFourCornerCode for U+71AF (熯). Current Value: 9403.4 Expected Value: 9483.4 Reasoning: Left Component: I note that U+706F (灯) is currently listed as 9182.0. Based on this, I would expect any character with the Fire radical on the left to follow the pattern 9_8_._. I believe the third digit 0 in the current value for 熯 is an error, as the bottom of the Fire radical is typically encoded as 8. Right Component: The right-hand side is identical to U+6F22 (漢), which is encoded as 3413.4. Therefore, I believe 熯 should logically match the pattern _4_3.4. Reference: My understanding is supported by Shirakawa Shizuka's dictionary Jitsū (字通), accessed via JapanKnowledge.com, which lists it under the code 9483. Thank you for your time and for reviewing this correction.
Date/Time: Sat Jan 31 17:32:47 PT 2026
ReportID: ID20260131173247
Name: Eiso Chan
Report Type: PRI Feedback
Opt Subject: kRSUnicode value for U+2A7EE
The current kRSUnicode value for U+2A7EE is 22.5, which is derived from the Chinese surname 欧阳/歐陽. The radical of 区 and 區 are both R23. The corresponding traditional form (WS2024-00318:GXM-00530 ⿰區昜) has been included in IRG WS2024 project, and the radical has been confirmed as R23. Therefore, I suggest updating the kRSUnicode value for U+2A7EE as 23.5.
Date/Time: Thur Feb 05 12:16:05 PT 2026
ReportID: ID20260205121605
Name: Michel Mariani
Report Type: PRI Feedback
Opt Subject: PRI 534 - kSemanticVariant issues
- In the `Unihan_Variants.txt` data file for Unicode 17.0, the following entries contain "asymmetrical" `kSemanticVariant` properties; normally, if A is a semantic variant of B, then it is assumed that B is also a semantic variant of A: U+34C1 kSemanticVariant U+7F51 - This can be fixed by adding these new entries: U+3F16 kSemanticVariant U+2CEAC U+4E0C kSemanticVariant U+2CEA2 U+50CF kSemanticVariant U+2CEA8 U+5149 kSemanticVariant U+2CEA7 U+5152 kSemanticVariant U+20487 U+5353 kSemanticVariant U+2CEA5 U+5C35 kSemanticVariant U+2EC63 U+5E72 kSemanticVariant U+2CEAD U+5E79 kSemanticVariant U+2CEAD U+65E6 kSemanticVariant U+2CEA3 U+6EDA kSemanticVariant U+2CEA4 U+6EFE kSemanticVariant U+2CEA4 U+7217 kSemanticVariant U+244B9 U+74E5 kSemanticVariant U+2CEAC U+78D9 kSemanticVariant U+2CEA4 U+8B5C kSemanticVariant U+8AE9 U+8C61 kSemanticVariant U+2CEA8 U+8DB3 kSemanticVariant U+2CEA3 U+24B24 kSemanticVariant U+2CEAC U+2DE30 kSemanticVariant U+2CEAA - And also update (extend) these entries to: U+5B2A kSemanticVariant U+2174F U+21D13 - Note that additional data separated from the added code points by a less-than sign (<) may be needed, but this would require appropriate linguistic expertise then... - As a side note, be warned that the contact form has been replacing all original tabulation characters by spaces in this report...
Date/Time: Fri Feb 06 12:10:43 PT 2026
ReportID: ID20260206121043
Name: Michel Mariani
Report Type: PRI Feedback
Opt Subject: PRI 534 - "self-variant" issues in Unihan DB
In the Unihan_Variants.txt data file, only two entries show unexpected "self-variants": • U+2D016 𭀖U+2D016 kSemanticVariant U+5398 should probably be changed to: U+2D016 kSemanticVariant U+5398 • U+7274 牴
U+7274 kSpecializedSemanticVariant U+7274 U+89DD should probably be changed to: U+7274 kSpecializedSemanticVariant U+89DD or, perhaps, the variant U+62B5 抵 was intended instead of U+7274 牴, in which case more changes would be needed across several entries...
Date/Time: Thu Feb 12 21:23:16 PT 2026
ReportID: ID20260212212316
Name: John Wilcock
Report Type: PRI Feedback
Opt Subject: PRI 534 - Mismatches between delimiter and UCD for UAX38
Here is a list of properties for where the delimiter attribute is listed as space, but the property only contains a single value. In some cases, this might be desirable for future extensibility, but in other cases, such as kKarlgren, the property is only single-valued and will not change. kOtherNumeric kTayNumeric kIBMJapan kIICore kIRGDaeJaweon kIRGHanyuDaZidian kIRGKangXi kJIS0213 kJis0 kJis1 kKangXi kKarlgren kMainlandTelegraph kMatthews kMorohashi kTaiwanTelegraph kXerox kZVariant
Date/Time: Tue Feb 17 19:45:01 PT 2026
ReportID: ID20260217194501
Name: Harriet Riddle
Report Type: PRI Feedback
Opt Subject: PRI 534
UTC-00882 can be horizontally extended to U+32562, and UTC-00891 can be horizontally extended to U+327F2.