The sections below contain links to permanent feedback documents for the open Public Review Issues as well as other public feedback as of July 3, 2025 - Oct 6, 2025, since the previous cumulative document was issued prior to UTC #185 (Oct 6, 2025).
The links below go directly to open PRIs and to feedback documents for them, as of Oct 6, 2025
The links below go to locations in this document for feedback.
Feedback routed to CJK & Unihan Working Group for evaluation [CJK]
Feedback routed to Script Encoding Working Group for evaluation [SEW]
Feedback routed to Properties & Algorithms Working Group for evaluation [PAG]
Feedback routed to Emoji Standard & Research Working Group for evaluation [ESC]
Feedback routed to Editorial Working Group for evaluation [EDC]
Other Reports
Date/Time: Wed July 16 23:16:48 PT 2025
ReportID: ID20250716231648
Name: wwzrh
Report Type: Report Error in Publication/Data
Opt Subject: 关于Unihan_Readings中kMandarin读音问题
https://www.unicode.org/reports/tr38/tr38-38.htmlModifications Proposed Update Unicode Standard Annex 38 Unicode Han Database (Unihan) Unicode 17.0.0 ------------------------------- 关于Unihan_Readings中kMandarin读音： 查对《通用规范汉字字典》[商务印书馆]2013、《新华字典》(第12版）[商务印书馆]2021、《现代汉语词典》[商务印书馆]（2016_第7版）、《现代汉语规范词典》 [语文出版社]（2022_第4版） V17.0.0中Unihan_Readings中kMandarin读音建议改为： U+5D74 嵴 jǐ 建议改为： jí U+752F 甯 níng 建议改为： nìng U+6E51 湑 xū 建议改为： xù U+574B 坋 bèn 建议改为： fèn U+696F 楯 dùn 建议改为： shǔn U+8274 艴 fú 建议改为： bó U+7854 硔 hóng 建议改为： gǒng U+5B1B 嬛 huán 建议改为： xuān U+787F 硿 kōng 建议改为： kòng U+78CF 磏 lián 建议改为： qiān U+5B56 孖 mā 建议改为： zī U+84C2 蓂 míng 建议改为： mì U+5594 喔 ō 建议改为： wō U+57E4 埤 pí 建议改为： pì U+756C 畬 shē 建议改为： yú U+9062 遢 ta 建议改为： tā U+5FD2 忒 tè 建议改为： tēi U+7EE8 绨 tí 建议改为： tì U+753A 町 tǐng 建议改为： dīng U+6DB4 涴 wò 建议改为： yuān U+54BA 咺 xuǎn 建议改为： xuān U+70FB 烻 yàn 建议改为： shān U+5895 墕 yàn 建议改为： yān U+7E47 繇 yáo 建议改为： yóu U+6EE7 滧 yáo 建议改为： xiào U+6014 怔 zhēng 建议改为： zhèng
Date/Time: Fri July 18 23:22:15 PT 2025
ReportID: ID20250718232215
Name: wwzrh
Report Type: Report Error in Publication/Data
Subject: V17.0 Unihan中U+275C8（ ）kMandarin错误
# Unihan_Readings.txt # 日期： 2025-04-25 00：00：00 GMT [吉隆坡] # Unicode 版本 17.0.0 -------------------------- 查阅《汉语大字典》U+275C8（𧗈）kMandarin错误： U+275C8 k普通话 “n”读音应为“nú”（𧗈）
Date/Time: Sun Aug 24 12:26:51 PT 2025
ReportID: ID20250824122651
Name: Michel Mariani
Report Type: Report Error in Publication/Data
Subject: [Unihan/CJK] Incorrect representative glyph
In the code charts for Versions 6.1 through 17.0 of the Unicode Standard, the T-source representative glyph TC-3B23 for U+2AA90 is ⿸虍文 (duplicate of U+8654) but was actually ⿸广⿱七文 before Unicode 6.1 .If this duplication is deemed incorrect, then the glyph for U+2AA90 should probably be reverted to its Unicode 6.0 version, otherwise its kRSUnicode property value should be updated: U+2AA90 kRSUnicode 53.6 would be: U+2AA90 kRSUnicode 141.4
Date/Time: Wed Sept 03 17:49:24 PST 2025
ReportID: ID20250903174924
Name: Eiso Chan
Report Type: Report Error in Publication/Data
Opt Subject: UAX 45
There are some characters of UAX #45 have been encoded, so the following entries should be updated accordingly in USourceData file. UTC-00794;ExtB;U+20B24;29.3;;;WL EFD1;;; UTC-00804;ExtH;U+31F00;36.1;;;WL EFDC;;; UTC-00805;ExtB;U+248E9;96.-1;;王;WL EF84;;; UTC-00810;ExtB;U+27FB7;157.0;;;WL EF76;;; UTC-00814;ExtB;U+20089;4.1;;;WL EFF6;;; UTC-00822;UTC-00077;U+9FB4;3.1;;;WL EFF4;;; UTC-00823;UTC-00079;U+9FB6;1.3;;;WL EFE3;;; UTC-00824;UTC-00080;U+9FB7;1.3;;;WL EFE0;;; UTC-00829;ExtB;U+201A2;9.0;;;WL EFA2;;; On the other hand, UTC could do the horizontal extensions for U+20089 (UTC-00814), U+201A2 (UTC-00829), U+20B24 (UTC-00794), U+248E9 (UTC-00805), U+27FB7 (UTC-00810), U+31F00 (UTC-00804) in future.
Date/Time: Mon Sep 08 07:22:14 PDT 2025
ReportID: ID20250908072214
Name: Ken Lunde
Report Type: Report Error in Publication/Data
Opt Subject: Additional kRSUnicode property values
Add the following as secondary kRSUnicode property values: U+2D1DD: 46.5 U+301FF: 151.5 U+31465: 154'.5 U+32515: 29.5 U+32517: 33.5 U+32518: 32.5 U+32522: 140.5 U+32525: 82.5 U+32527: 67.5 U+32549: 132.5
Date/Time: Tue Sep 09 20:54:37 PST 2025
ReportID: ID20250909205437
Name: Brian Guo
Report Type: Report Error in Publication/Data
Opt Subject: Wrong radical in 995F 饟
The character 995F 饟 has two radicals listed: 食 184.17 and 馬 187.17. The latter is clearly an error.
Date/Time: Tue Sep 09 21:35:48 PST 2025
ReportID: ID20250909213548
Name: Eiso Chan
Report Type: Report Error in Publication/Data
Opt Subject: RS values for U+995F
The kRSUnicode property value for U+995F 饟 is "184.17 187.17", The second one was added since Unicode, 16.0.0. John Jenkins suggested adding the second one in L2/23-059 (p. 4), but he showed the form of the character is 厂, not 饟.This suggestion had been accepted in CJK & Unihan WG meeting for UTC #175. See Section 22 of L2/23-082 (p. 31). It looks a typo. This suggestion is cited from 《商務新字典》. I suggested removing the second one tentatively. I will try to check this issue in 《商務新字典》 when I have the chance.
Date/Time: Tue Sep 16 22:31:43 PT 2025
ReportID: ID20250916223143
Name: Eiso Chan
Report Type: Report Error in Publication/Data
Opt Subject: Annotations for U+2F81D and U+2F82D
In IRG N2778, TCA requested to move T5-2129 to U+20674 and modify the T glyph for U+2F81D. Currently, the glyphs for U+20674 and U+2F81D are the same. TCA also requested to move T6-2F38 to U+20161 and modify the T glyph for U+2F82D. Currently, the glyphs for U+20161 and U+2F82D are the same. Suggest updating the Name List as below. 2F81D CJK COMPATIBILITY IDEOGRAPH-2F81D x 20674 : 51F5 2F82D CJK COMPATIBILITY IDEOGRAPH-2F82D x 20161 : 5351
Date/Time: Wed Sep 24 03:26:15 PT 2025
ReportID: ID20250924032615
Name: M
Report Type: General Feedback
Opt Subject: Variant Suggestion for Unihan Data
Since these are U+3A41 㩁 zVariant U+6409 搉 U+6409 㩁 zVariant U+3A41 搉 I think these should be too U+5BC9 寉 zVariant U+96BA 隺 U+96BA 寉 zVariant U+5BC9 隺
Date/Time: Thu Sep 25 11:56:04 PT 2025
ReportID: ID20250925115604
Name: Philippe Verdy
Report Type: Report Error in Publication/Data
Opt Subject: U+4724 - kstrokes=13 should be 9
U+4724 (䜤) is the simplified version of U+9FC1 (鿁); both are sorted But both display kTotalStrokes=13 which is correct only for the traditional U+9FC1. https://www.unicode.org/cgi-bin/GetUnihanData.pl?codepoint=4724 (䜤) https://www.unicode.org/cgi-bin/GetUnihanData.pl?codepoint=9FC1 (鿁) For the simplified U+4724, it should be kTotalStrokes=9 (with 4 strokes removed from the radical to use its simplified variant instead of the Kangxi variant) This is an old bug in UniHan data for U+4724. Does the IRC has methods to check and review the strokes counts, notably for CJK characters that are encoded since long (like here in the first extension-A) ? I have other inconsistant kTotalStrokes for various other ideographs that have been encoded in the past, notably because they mixed the stroke count from the basic (traditional) Kangxi radical with the stroke count of the extended (simplified) radical, and computed a wrong total. Additional feedback: Note that i made an error, this should be probably 8, not 9, accirdikg to the standard stroke coint of the extended radical, bit infoi'd some variants where the z shaped stroke may be deawn as two stroke. Anyway such error occurs général l'y with ideogramhs whose radical is an exte'ded radical and not a Kangxi radical. In Unicode charts these are indicated by one or more single quotes after the base Kangxi radical. And frequently in that case there is a confusion between these radicals, and it really seems that kTotalStrokes where computed algorithmically using an incorrect assumption about the radical stroke count, by just adding the residual strokes to the Kangxi radical strokes. I know also that kTotalStrokes is informative, not normative. But i also know that the IRG is working to add a new property for the first stroke, which is fur now provisional and only present in the recently encoded ideographs. However i found also incohérent kTotalStrokes also in the latest CJK extension J in Unicode 17.0. Such corrections for kTotalStrokes should not affect radical-stroke-index collation order, un like thecrectly added provisional first stroke, which is still not usable for now in collation keys using the bit pattern described ib the Unicode annex about it. So even if this lakes time to check again kTotalStrokes on all existing ideographs, at least you should start by those encoded using an extended non-Kangxi radical whose strokes count is différent from base Kangxi radicals.
Date/Time: Mon Sept 29 18:34:57 PT 2025
ReportID: ID20250929183457
Name: Michel Mariani
Report Type: Report Error in Publication/Data
Opt Subject: [Unihan/CJK] List of KP-Source Mappings
Based on morphological considerations, the following entries could be added to the current list of KP-source suboptimal mappings in UTN #50: Source Reference Current Better Notes KP0-CDA9 U+5609 嘉 U+2B158 𫅘 Mentioned in 23041-kp-alpha-review.pdf, suggesting that U+2B158 should actually be reverted to its glyph before Unicode 6.1: ⿱ 茄 KP1-4AD6 U+23402 𣐂 U+233CB 𣏋 Especially relevant since the recent JMJ horizontal extension KP1-8852 U+9907 餇 U+296B1 𩚱 Possible component error (confusion): 冋 vs. 同 KP1-8FF5 U+2A279 𪉹 U+400B 䀋 Layout difference: ⿰①⿱②③・⿱⿰①②③
Date/Time: Sat Oct 04 04:44:16 PT 2025
ReportID: ID20251004044416
Name: Leah Hicks
Report Type: Report Error in Publication/Data
Opt Subject: kVietnamese value for 蘶 is missing
Dear Consortium, I have located the Vietnamese pronunciation of this character 蘶 U+8636 in the book Dictionarium Anamitico-Latinum: ngùy. Please see image below for evidence. Apologies if this in the incorrect method for suggesting character edits, please let me know if there is another way. https://imgur.com/a/r1fSrT0 Sincerely, Leah Hicks
Date/Time: Tue Oct 07 09:44:19 PT 2025
ReportID: ID20251007094419
Name: M
Report Type: Report Error in Publication/Data
Opt Subject: Variant Suggestion for Unihan Data
U+8EB1 kZVariant U+8EB2 U+8EB2 kZVariant U+8EB1
Date/Time: Tue Oct 07 13:48:30 PT 2025
ReportID: ID20251007134830
Name: M
Report Type: Report Error in Publication/Data
Opt Subject: Variant Suggestion for Unihan Data
U+514C zVariant U+5151 U+5151 zVariant U+514C
Date/Time: Tues Oct 14 11:04:51 PT 2025
ReportID: ID20251014110451
Name: Eiso Chan
Report Type: Report Error in Publication/Data
Opt Subject: RS for 𦉓 U+26253
IRG discussed the RS issue for WS2024-03041:GCW-00191 ⿰缶鸟 https://hc.jsecs.org/irg/ws2024/app/?id=03041 . IRG decided to use Rad. 鸟 as the primary radical, and Rad. 缶 as the secondary radical. The IRG experts hope to keep the RS rule consistent, so Rad. 鳥 should be the primary radical and Rad. 缶 should be the secondary radical for 𦉓 U+26253. U+26253 kRSUnicode 196.6 121.11
Date/Time: Tues Oct 14 11:11:26 PT 2025
ReportID: ID20251014111126
Name: Eiso Chan
Report Type: Report Error in Publication/Data
Opt Subject: RS for U+2D04C 𭁌, U+2D051 𭁑, U+2D059 𭁙
IRG discussed WS2024-00324:VN-F2085 ⿰半丙. https://hc.jsecs.org/irg/ws2024/app/?id=00324 IRG has confirmed the radical of the character with the left component 半 should be 十 not 八. U+2D04C kRSUnicode 24.7 U+2D051 kRSUnicode 24.9 U+2D059 kRSUnicode 24.12
Date/Time: Thur Aug 21 09:13:28 CST 2025
ReportID: ID20250821091328
Name: Saish S K
Report Type: General Feedback
Opt Subject: Separate archaic/redundant characters from modern
Problem: Currently, Unicode groups archaic, obsolete, and modern characters together within certain blocks. This mixing makes it difficult for users, developers, linguists, and typographers to distinguish between characters actively used today versus those that are historical or obsolete. Examples: In the Latin Extended-A block, letters such as ƀ (B with stroke, historical) appear alongside standard modern letters like A, B, C. In Greek and Coptic, archaic letters like ϝ (digamma) are in the same blocks as regularly used modern Greek letters like α, β, γ. Old Indic or Brahmi characters are sometimes placed near modern Devanagari letters, causing confusion. Impact: Users & Learners: Difficulty in identifying which letters are actively used versus historical. Font Designers: Increased complexity in font design and testing, as fonts must support characters that are rarely or never used. Software Developers & Researchers: Parsing, search, and text processing become error-prone; historical data analysis and NLP tools struggle with mixed blocks. Solution: Separate modern letters from archaic or obsolete ones by creating dedicated “Historic/Archaic” blocks. Add clear metadata to each character indicating status: modern, obsolete, archaic, or historic. Keep modern characters consolidated in their own primary blocks to simplify usage and tooling. Rationale: Readability & Usability: Easier for learners and users to identify active letters. Software & Fonts: Developers and typographers can better target modern characters without accidentally including archaic symbols. Academic & Research Clarity: Historical linguists and NLP researchers benefit from clear separation, reducing ambiguity in datasets. Thank you for considering this feedback. I believe separating modern and archaic characters will significantly improve usability, clarity, and accessibility across Unicode implementations.
Date/Time: Sat Aug 16 06:44:46 PT 2025
ReportID: ID20250816064446
Name: Mikhail Merkuryev
Report Type: General Feedback
Subject: TR14: More discussion about my rule
Do not break numbers from letters, when divided with unresolved hyphen AL HY × (NU IS PR) (NU IS PO) HY × AL In Russian/Ukrainian, there are lots of places with number+hyphen+text: 2-й = 2nd ВАЗ-2101 = VAZ 2101, car model Терминатор-2 = Terminator 2, film 9-этажка = 9-storey block Actually was bugged with such browsers’ behaviour while editing some wikis. Need more discussion, maybe just write as a note rather than strict rule. And just a note (no strict rule): in Russian/Ukrainian some short particles are written with a hyphen, but morphological analysis is needed whether you can break: давай-ка (let’s, breaking is discouraged); да-с (yes milord, breaking is impossible).
Date/Time: Sun Aug 24 09:53:16 PT 2025
ReportID: ID20250824095316
Name: Mikhail Merkuryev
Report Type: General Feedback
Opt Subject: TR14: multiple chars GL→WJ
WJ is for places where Unicode usually breaks, and we should absolutely disable this feature. GL is for places where Unicode should not break after, but in some soft circumstances it can break before. This division into WJ and GL contradicts with another rule: do not break before marks. So I suggest moving Mark/any (M*) + Non-tailorable/glue (GL) → WJ. Do not break before, do not break after. Examples: 035C combining double breve below FE20 combining ligature left half 16FE4 Khitan small script filler
Date/Time: Tue Aug 26 05:31:17 PST 2025
ReportID: ID20250826053117
Name: Roger Moser
Report Type: Report Error in Publication/Data
Opt Subject: Upper case of ß (00DF) is ẞ (1E9E)
There is the error in http://www.unicode.org/Public/UCD/latest/ucd/UnicodeData.txt: The upper case of LATIN SMALL LETTER SHARP S (00DF) is LATIN CAPITAL LETTER SHARP S (1E9E). But this information is missing. Therefore change 00DF;LATIN SMALL LETTER SHARP S;Ll;0;L;;;;;N;;;;; to 00DF;LATIN SMALL LETTER SHARP S;Ll;0;L;;;;;N;;;1E9E;;1E9E
Date/Time: Mon Aug 27 17:06:31 PT 2025
ReportID: ID20250827170631
Name: Daniel Bünzli
Report Type: General Feedback
Subject: UAX42 Modification section is missing the renames
Hello, I noticed that in the description of revision 37 of UAX #42. The following lines are missing: * Renamed attribute `kRSTUnicode` to `kTGT_RSUnicode` * Renamed attribute `kSrc_NushuDuben` to `kNSHU_DubenSrc` * Renamed attribute `kReading` to `kNSHU_Reading` Thanks for your work on keeping the ucdxml alive. Best,5 Daniel
Date/Time: Tue Sep 16 15:49:04 PT 2025
ReportID: ID20250916154904
Name: Nikolay Sivov
Report Type: Report Error in Publication/Data
Opt Subject: Incorrect rule LB15b description
Current description at https://www.unicode.org/reports/tr14/tr14-55.html#LB15b says: Do not break before an unresolved final punctuation that lies at the end of the line, before a space, before a prohibited break, or before an unresolved quotation mark, even after spaces. The part "even after spaces" should be removed I believe. It's not reflected in the rule grammar and looks like it was copied from LB15a description.
Date/Time: Mon Sep 29 04:14:29 PT 2025
ReportID: ID20250929041429
Name: Bruno Haible
Report Type: Report Error in Publication/Data
Opt Subject: LineBreak: inconsistent handling of future emojis
UAX #14 has a rule (LB30b) that treats unassigned characters in the "future" emoji base range [\p{Extended_Pictographic}&\p{Cn}] like emoji
base characters (EB):https://www.unicode.org/reports/tr14/#LB30b
This makes perfect sense.
The Extended_Pictographic property is specified in the file ArchiveVersions/17.0.0/ucd/emoji/emoji-data.txt. It includes some characters
listed as "". Among these, there are:
* U+1FFFD
* U+1F8FF
(There are more of them, but I'm picking these two for the sake of the discussion.)
This is perfectly consistent with ArchiveVersions/17.0.0/ucd/UnicodeData.txt: this file does not list U+1F02C nor U+1F8FF as assigned characters;
hence they are unassigned.
Now, the file ArchiveVersions/17.0.0/ucd/auxiliary/LineBreakTest.txt treats these two sample future emoji base characters differently:
* In LineBreakTest.txt line 1527 there is a test case that allows a line break between U+0023 and U+1FFFD. This makes perfect sense: When U+1FFFD
might be assigned to an emoji base in the future, it will behave like a character with line breaking property EB or ID. It makes sense to allow a
line break there.
* In LineBreakTest.txt line 1647 there is a test case that *disallows* a line break between U+0023 and U+1F8FF. This makes no sense: When U+1F8FF
might be assigned to an emoji base in the future, it *should* behave like a character with line breaking property EB or ID. Thus it *should*
allow a line break there.
In this line the justification is rule LB28. But this rule https://www.unicode.org/reports/tr14/#LB28 says "Do not break between alphabetics".
While unassigned characters in general (line breaking property XX) are mapped to AL by rule LB1 https://www.unicode.org/reports/tr14/#LB1, this
rationale does not hold for future emoji base characters: it *should* behave like EB or ID, not AL.
* The test cases with character U+1F8FF in the following lines of LineBreakTest.txt have the same problem:
267
269
543
545
1095
1097
1371
1373
1647
1649
3581
4959
4961
5235
5237
5513
7719
7721
10757
11033
14619
14621
14895
14897
15171
15173
15449
16827
16829
17103
17105
17381
19037
(None at this time.)
Date/Time: Wed July 16 09:17:22 PT 2025
ReportID: ID20250716091722
Name: Joel Strasser
Report Type: General Feedback
Subject: Preference on ẞ over SS when converting ß to upper
According to the german speaking Rechtschreibrat the preference when converting the small letter sharp s "ß" to its capital form it is now preferred to use the capital letter sharp s "ẞ" over the combination of two capital letter s "SS". https://www.rechtschreibrat.com/DOX/RfdR_Amtliches-Regelwerk_2024.pdf § 25 E3: Bei Schreibung mit Großbuchstaben ist neben der Verwendung des Groß buchstabens ẞ auch die Schreibung SS möglich: Straße – STRAẞE – STRASSE. In comparison the previous version stated: https://www.rechtschreibrat.com/DOX/rfdr_Regeln_2016_redigiert_2018.pdf § 25 E3: Bei Schreibung mit Großbuchstaben schreibt man SS. Daneben ist auch die Verwendung des Großbuchstabens ẞ möglich. Beispiel: Straße – STRASSE – STRAẞE. Which indicates that the preference has changed. This has also been reflected in DIN 5008.
Date/Time: Mon Sept 15 06:25:51 PT 2025
ReportID: ID20250915062551
Name: Jakub Jelinek
Report Type: Report Error in Publication/Data
Subject: Table 4-8 not updated for Unicode 17
The 4-8 table has not been updated for Unicode 17.0, although UnicodeData.txt and the character pdfs suggest it should have been. In particular, the 2A700..2B739 NR2 “CJK UNIFIED IDEOGRAPH-” line IMHO should have been changed to 2A700..2B73F NR2 “CJK UNIFIED IDEOGRAPH-” and the 2B820..2CEA1 NR2 “CJK UNIFIED IDEOGRAPH-” line should have been changed to 2B820..2CEAD NR2 “CJK UNIFIED IDEOGRAPH-” and a new line should be added: 323B0..33479 NR2 “CJK UNIFIED IDEOGRAPH-” See the UnicodeData.txt changes: @@ -39215,14 +39671,15 @@ FFFD;REPLACEMENT CHARACTER;So;0;ON;;;;;N 1FBF7;SEGMENTED DIGIT SEVEN;Nd;0;EN; 0037;7;7;7;N;;;;; 1FBF8;SEGMENTED DIGIT EIGHT;Nd;0;EN; 0038;8;8;8;N;;;;; 1FBF9;SEGMENTED DIGIT NINE;Nd;0;EN; 0039;9;9;9;N;;;;; +1FBFA;ALARM BELL SYMBOL;So;0;ON;;;;;N;;;;; 20000;;Lo;0;L;;;;;N;;;;; 2A6DF;;Lo;0;L;;;;;N;;;;; 2A700;;Lo;0;L;;;;;N;;;;; -2B739;;Lo;0;L;;;;;N;;;;; +2B73F;;Lo;0;L;;;;;N;;;;; 2B740;;Lo;0;L;;;;;N;;;;; 2B81D;;Lo;0;L;;;;;N;;;;; 2B820;;Lo;0;L;;;;;N;;;;; -2CEA1;;Lo;0;L;;;;;N;;;;; +2CEAD;;Lo;0;L;;;;;N;;;;; 2CEB0;;Lo;0;L;;;;;N;;;;; 2EBE0;;Lo;0;L;;;;;N;;;;; 2EBF0;;Lo;0;L;;;;;N;;;;; @@ -39773,6 +40230,8 @@ FFFD;REPLACEMENT CHARACTER;So;0;ON;;;;;N 3134A;;Lo;0;L;;;;;N;;;;; 31350;;Lo;0;L;;;;;N;;;;; 323AF;;Lo;0;L;;;;;N;;;;; +323B0;;Lo;0;L;;;;;N;;;;; +33479;;Lo;0;L;;;;;N;;;;; E0001;LANGUAGE TAG;Cf;0;BN;;;;;N;;;;; E0020;TAG SPACE;Cf;0;BN;;;;;N;;;;; E0021;TAG EXCLAMATION MARK;Cf;0;BN;;;;;N;;;;; Both of the TANGUT IDEOGRAPH- entries also need adjustment, in one case from 187F7 to 187FF and in another case from 18D08 to 18D1E. Plus I wonder why there aren't extra entries for TANGUT COMPONENT- ranges, those don't have the NR1/NR2 rules, but would need instead have names as prefix followed by 3+ digit decimal number starting at some base. But there are 883 of those, so might be worth handling it specially.
Date/Time: Tue Sep 16 19:28:27 PT 2025
ReportID: ID20250916192827
Name: Martin J. Dürst
Report Type: Report Error in Publication/Data
Opt Subject: Wrong reference link in newest TR41
At https://www.unicode.org/reports/tr41/tr41-36.html#Unicode, there is a link to Version 17.0.0, with the text "https://www.unicode.org/versions/Unicode17.0.0/", but with a mistaken underlying link of https://www.unicode.org/versions/Unicode16.0.0/.
Date/Time: Fri Sep 19 17:41:27 PT 2025
ReportID: ID20250919174127
Name: David Corbett
Report Type: Report Error in Publication/Data
Opt Subject: Typos in The Unicode Standard, Version 17.0
Version 17.0 of the standard has some typos. In chapter 7, “clocks, respectively, of Xhosa orthography” should start “clicks”. In chapter 11, in the section on Anatolian hieroglyphs, the comparison starting “Just as for Egyptian hieroglyphs” is wrong, because complex Egyptian layout can now be represented in plain text. In chapter 13, “jyna” should be “jnya”. In chapter 16, in “U+1E6F5 TAI YO SIGN OM is used as an alternative of U+1E6E7 TAI YO LETTER O + U+1E6E7 TAI YO LETTER O”, the second U+1E6E7 should be U+1E6D6 TAI YO LETTER MO. In chapter 17, in the /dudu/ example, the second vowel sign is missing. This was correct in version 16.0. In chapter 19, “inconsistent.There” should be “inconsistent. There”.
Date/Time: Sun Sep 21 17:09:23 PT 2025
ReportID: ID20250921170923
Name: Linus Sturm
Report Type: Report Error in Publication/Data
Opt Subject: (Believed to be) Error in Chart 1D200–1D24F
To Whom It May Concern, In the character chart for “Ancient Greek Musical Notation” (range 1D200–1D24F, current, Unicode-17 version), there are present-day equivalents given in the character notes. Some of these notes contain notes which denote their pitch through primes, as can be seen by the following example: “1D208 GREEK VOCAL NOTATION SYMBOL-9 […] • instrumental first sharp of e´” (The Unicode Standard, version 17, p. 1724, left column) However, the character used for the prime is not the—as far as I am aware—correct one, which is 2032 “PRIME” (′); but instead 00B4 “ACUTE ACCENT” (´). I therefore propose this error be corrected. If I am mistaken and this character was correctly used, I would still welcome a reply, be it only to not correct this usage I currently know to be wrong in the future. Kind regards from northern Germany, Linus Sturm
(None at this time.)