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 May 24 10:30:17 PDT 2026
ReportID: ID20260524103017
Name: Simon Patrick
Report Type: Public Review Issue
Opt Subject: PRI #548: Amdts to Core Spec 18.0.0 beta [EDC]
Suggested corrections to the Core Specification, Section 22.3.1 (a) In Table 22.3, insert the following three entries in their alphabetical places: Chisoi Section 13.25 Ol Onal Section 13.11 Tolong Siki Section 13.24 (b) In paragraph #G42826 (“Exceptions”) leave out the fourth sentence “For the Myanmar script a second set of digits is encoded for the Shan language, and a third set of digits is encoded for the Tai Laing language.” and insert “For the Myanmar script, extra sets of digits are encoded for each of four other languages: Shan, Tai Laing, Pa’O, and Eastern Pwo Karen.” [These missing 5 sets of digits account for the disparity between the 64 sets of digits previously mentioned in this section (60 entries in the table plus four extra in the text), plus 9 sets of digits in Common, and the 780 characters (78 sets) in category Nd in the 18β version of DerivedGeneralCategory.txt.]
Date/Time: Tue May 26 17:27:22 PDT 2026
ReportID: ID20260526172722
Name: Michel Mariani
Report Type: Public Review Issue
Opt Subject: PRI 548 - Inconsistent name of new block [EDC]
https://blog.unicode.org/2026/05/unicode-180-beta-review-opens-for.html : "The largest set of additional characters is for the new Small Seal script with 11,328 ideographs." https://www.unicode.org/Public/draft/ucd/NamesList.txt : @@ 3D000 Small Seal 3FC3F https://www.unicode.org/Public/draft/ucd/Blocks.txt : 3D000..3FC3F; Seal In Blocks.txt, the name of the new block should be consistent with the other occurrences... https://www.unicode.org/Public/draft/ucd/Scripts.txt: 3D000..3FC3F ; Seal # Lo [11328] SEAL CHARACTER-3D000..SEAL CHARACTER-3FC3F https://www.unicode.org/Public/draft/ucd/UnicodeData.txt : 3D000;;Lo;0;L;;;;;N;;;;; 3FC3F;;Lo;0;L;;;;;N;;;;; https://www.unicode.org/Public/draft/ucd/SealSources.txt : # Small Seal Database Unicode 18.0 Character Code Charts https://www.unicode.org/Public/draft/charts/ : Nushu Seal Tangut Where Seal is a link to the code chart: https://www.unicode.org/Public/draft/charts/PDF/U3D000.pdf : Small Seal Range: 3D000–3FC3F And possibly many others.
Date/Time: Thu May 28 11:40:27 PDT 2026
ReportID: ID20260528114027
Name: Night Koo
Report Type: Public Review Issue
Opt Subject: Update annotations for CJK Strokes UVS [CHARTS]
Following the acceptance of UVS for CJK Strokes block, I suggest to update the annotations as follow to match existing glyphs under the variants whenever possible: 31C0 ㇀ CJK STROKE T • 2nd stroke of 5201 刁 ⁓ 31C0 FE00 � dotted T form • 2nd stroke of 51B0 冰 31C6 ㇆ CJK STROKE HZG • 1st stroke of 7FBD 羽 ⁓ 31C6 FE00 � curved Z form • 1st stroke of 5201 刁 ⁓ 31C6 FE01 rising H form • 1st stroke of 4E5F 也 31C9 ㇉ CJK STROKE SZWG • 3rd stroke of 5F13 弓 ⁓ 31C9 FE00 � slanted S form • 2nd stroke of 9A6C 马 31CF ㇏ CJK STROKE N • 3rd stroke of 5927 大 ⁓ 31CF FE00 � curved starting N form • 1st stroke of 5165 入 G source ⁓ 31CF FE01 � flat N form • 2nd stroke of 5EF4 廴 31D0 ㇐ CJK STROKE H • 1st stroke of 5927 大 ⁓ 31D0 FE00 � rising H form • 1st stroke of 4E03 七 31D1 ㇑ CJK STROKE S • 4th stroke of 4E2D 中 ⁓ 31D1 FE00 � slanted S form • 2nd stroke of 4E11 丑 31D2 ㇒ CJK STROKE P • 1st stroke of 4E42 乂 ⁓ 31D2 FE00 flat P form • 1st stroke of 4E4F 乏 31D4 ㇔ CJK STROKE D • 3rd stroke of 4E38 丸 ⁓ 31D4 FE00 � to bottom left form • 2nd stroke of 5FC4 忄 31D5 ㇕ CJK STROKE HZ • 2nd stroke of 56DB 四 ⁓ 31D5 FE00 � slanted Z form • 4th stroke of 4ECA 今 31D7 ㇗ CJK STROKE SZ • 2nd stroke of 5C71 山 ⁓ 31D7 FE00 � slanted S form • 2nd stroke of 4E1C 东 31DB ㇛ CJK STROKE PD • 1st stroke of 5DE1 巡 ⁓ 31DB FE00 � slanted SD form • 1st stroke of 5973 女 31DC ㇜ CJK STROKE PZ • 4th stroke of 248E5 𤣥 ⁓ 31DC FE00 � upwards T form • 3rd stroke of 516C 公 • 4th stroke of 5F18 弘 31DD ㇝ CJK STROKE TN • stylistic alternative of N stroke in some fonts ⁓ 31DD FE00 � horizontal H curved N form • 1st stroke of 5165 入 non-G source ⁓ 31DD FE01 > upwards T flat N form • Last stroke of 8FB6 辶 31E5 CJK STROKE SZP • 8th stroke of 594A 奊 ⁓ 31E5 FE00 � slanted S form • 3rd stroke of 4E13 专
Date/Time: Mon June 15 17:11:42 PT 2026
ReportID: ID20260615171142
Name: Ben Denckla
Report Type: Public Review Issue
Opt Subject: asymmetric detail in new Hebrew points [CHARTS]
DAGESH HAZAQ MUDGASH provides the detail "used in texts that distinguish dagesh hazaq from dagesh qal" SHEVA NA MUDGASH provides no such detail. The analogous detail would be "used in texts that distinguish sheva na from sheva nach" (or naḥ (h with combining dot below) instead of nach if Unicode is allowed here) In my opinion, either both of these code points should have these details, or neither should. I.e. I can't see any reason for an asymmetry.
Date/Time: Wed June 17 23:53:57 PT 2026
ReportID: ID20260617235357
Name: Jett Trang
Report Type: Public Review Issue
Opt Subject: N5344R2 Seal: Glyph confusion for U+3F80D & 3F80E. [CHARTS]
Reference: ISO/IEC JTC 1/SC 2/WG2 N5344R2 Issue: > In the proposed Small Seal block, the THX reference glyphs for U+3F80D and U+3F80E lack clear visual distinction. The separation of these two characters into distinct code points is based on Duan, Ngyok-dzoi’s (DYC) theory, which differentiates the components "彖" (U+5F56) and "𧰲" (U+27C32). Although modern paleography suggests this distinction may be a fabrication by Duan, N5344R2 still separates them to reflect this textual tradition. Recommendation: To maintain logical consistency and prevent user confusion, the reference glyphs must visually reflect this encoding separation. Currently, the THX glyphs for both code points appear nearly identical. If strict adherence to raw source scans is not mandatory, I recommend modifying the THX glyph for U+3F80E to align with the distinct component structure shown in its DYC column. I acknowledge, however, that your team may have already noted this issue and retained the current glyphs purely to maintain strict fidelity to the original printed texts.
Date/Time: Mon June 22 15:50:26 PT 2026
ReportID: ID20260622155026
Name: Jules Bertholet
Report Type: Public Review Issue
Opt Subject: Definition of "Grapheme extender" is incorrect [PAG]
D59 in §3.6.3 of the Core Specification says: D59 Grapheme extender: A character with the property Grapheme_Extend. Grapheme extender characters consist of all nonspacing marks, ZERO WIDTH JOINER, ZERO WIDTH NON-JOINER, U+FF9E HALFWIDTH KATAKANA VOICED SOUND MARK, U+FF9F HALFWIDTH KATAKANA SEMI-VOICED SOUND MARK, and a small number of spacing marks. A grapheme extender can be conceived of primarily as the kind of nonspacing graphical mark that is applied above or below another spacing character. ZERO WIDTH JOINER and ZERO WIDTH NON-JOINER are formally defined to be grapheme extenders so that their presence does not break up a sequence of other grapheme extenders. […] However, this definition does not match the actual property assignments: U+200D ZERO WIDTH JOINER does not have the Grapheme_Extend property in DerivedCoreProperties.txt. I believe this should be corrected not be changing the spec, but instead by changing the property assignments in `DerivedCoreProperties.txt` to make U+200D be Grapheme_Extend, and changing the derivation of Grapheme_Cluster_Break=Extend to exclude 200D.
Date/Time: Wed June 24 09:00:03 PT 2026
ReportID: ID20260624090003
Name: Peter Constable
Report Type: Public Review Issue
Opt Subject: PRI #548: conformance notes for D57h [PAG]
The intent of UTC decision 187-C42 was to improve comformance language to mitigate against malicious use of variation selector characters, and new text in 3.6.2 helps. However, the current conformance note following D57h has limited effect for that goal: "A conformant implementation must not interpret a misplaced variation selector as a request to modify the glyph shape of a preceding character." This doesn't indicate that use of a misplaced variation selector _for any other purposed_ is also non-conformant. The paragraph preceding D57d does say, "Variation sequences are not intended as a general extension mechanism for the character encoding." The wording of that sentence is vague: someone might assert that an intentional use of a misplaced variation selector is not a _character encoding extension_ but is some other type of information representation mechanism. I suggest that the first note after D57h be revised as follows: "Any use of a misplaced variation selector is non-conformant. A comformant implementation must not interpret a misplaced variation selector." Related, it might be useful to add a statement somewhere regarding default ignorables along this line: "Any use of byte sequences within text with an expectation that they will be interpreted as non-printing characters (hence invisible to users) but with a purpose of representing other information is not conformant text representation. "Implementers are also advised that this technique can potentially be used as a security attack vector in applications. Any use of invisible characters for any purpose not explicitly defined in this standard is non-conformant."
Date/Time: Thu July 02 10:02:16 PT 2026
ReportID: ID20260702100216
Name: Ken Lunde
Report Type: Public Review Issue
Opt Subject: PRI #548 [CJK]
TCA reported on 2026-07-02 that the 心 component of the T-source glyphs for U+20CB9, U+21731, U+21DDE, U+22681, and U+22B44 is malformed, and provided an updated font to Michel as an attachment to the email. I confirmed that this issue was introduced in the Extension B code charts for Unicode Version 6.0 (2010).
Date/Time: Mon July 06 14:06:54 PT 2026
ReportID: ID20260706140654
Name: Marc Lodewijck
Report Type: Public Review Issue
Opt Subject: PRI #548 Minor issues in references to standards [CHARTS]
I noticed a few issues related to the naming and dating of some referenced standards in the Unicode code charts. I am reporting them here in case corrections are deemed appropriate. 1/ Publication year of ISO/IEC 13751 Reference found: ISO/IEC 13751:2000 -> should be ISO/IEC 13751:2001 Location: in the comment line for U+234A Issue: The correct designation should be ISO/IEC 13751:2001, not ISO/IEC 13751:2000. Although the standard was finalized in late 2000, its official publication date in the ISO catalogue is February 1, 2001, and the registered designation is therefore ISO/IEC 13751:2001. 2/ Use of "ISO" vs "ISO/IEC" in jointly developed standards The following standards were jointly developed by ISO and IEC, and ISO/IEC is the official designation registered in the ISO catalogue. In several places, the charts use ISO alone instead of ISO/IEC. A/ ISO 8859-6 -> should be ISO/IEC 8859-6 - In the subheader and notice line preceding U+0621 - In the subheader preceding U+0640 - In the subheader preceding U+064B B/ ISO 8859-8 -> should be ISO/IEC 8859-8 - In the subheader preceding U+05D0 C/ ISO 9995-7 -> should be ISO/IEC 9995-7 - In an alias line for U+21E7 - In an alias line for U+21E8 - In an alias line for U+2318 - In a comment line for U+237D - In the subheader preceding U+2380 - In the subheader preceding U+2396 - In a comment line for U+2425 - In the notice line preceding U+2BEC 3/ ISO 7000 incorrectly labeled as ISO/IEC Reference found: ISO/IEC 7000 -> should be ISO 7000 Location: in the comment line for U+1F4D6 Issue: ISO 7000 was not jointly developed by ISO and IEC. The correct reference is therefore ISO 7000-0790 (without "/IEC"). ########## No issues were found with references to the following standards (ISO or ISO/IEC as appropriate): ISO 1004:1995 ISO 2047 ISO 5426-2 ISO 6438 ISO 7000:2012 ISO 15919 ISO/IEC 646 ISO/IEC 6429:1992 ISO/IEC 8859-1
Date/Time: Mon July 06 15:20:03 PT 2026
ReportID: ID20260706152003
Name: suzuki toshiya
Report Type: Public Review Issue
Opt Subject: PRI 548: 18.14 "Seal" in Unicode 18.0.0 Beta [EDC]
Dear UTC experts, I read the explanation on Small Seal script in the chapter 18.14 on Unicode 18.0.0 Beta, and I want to propose small improvements in below. * Reflecting Modern Archeological Context: While Shuowen Jiezi (SWJZ) remains the primary reference for the Small Seal script, recent research on excavated artifacts has highlighted graphic differences between the Seal script preserved in SWJZ and that found on actual Qin dynasty materials. Nevertheless, the comprehensive repertoire, the 540-radical system, and the ordering of SWJZ remain fundamentally important for modern collation and reference. * Clarifying Timeline by Authorship Dates: To provide better technical and historical context, explicitly stating the specific years when the SWJZ, Daxu, Xiaoxu, and Duan Zhu (DYC) editions were authored or completed is more informative than merely mentioning the Imperial dynasties. Since the exact completion year of the Xiaoxu Ben is historically uncertain, the year of Xu Kai's passing (974 CE) has been introduced as the best alternative chronological reference. * Introducing Xinxiuzi and Structural Contrast: The Daxu Ben text actually contains two distinct categories of later emendations: Xinfuzi (新附字), which are separately listed at the end of each radical, and Xinxiuzi (新修字), which are merged directly into the main text and are visually indistinguishable from original entries. Defining both categories is crucial, as it provides the necessary context for the encoding principles described later in the document. * Correcting Typographical Description of Glyphs: The typographical description has been updated to accurately reflect that the traditional bounding box for Shuowen-based Small Seal characters is a vertical rectangle rather than a perfect square, and explains how modern digital typography adapts this form to uniform advance widths. * Addressing Missing Specification on Duplicated Entries: A completely new section, "Duplicated Entries," has been added to address a critical omission in the original text, explaining how redundant duplicate entries from the original SWJZ are systematically handled and resolved in the Unicode Standard to prevent duplicate encoding. --- ### Proposed Text Revision for Section 18.14 (Seal) Below is the complete revised text, incorporating all the improvements outlined above: ```markdown # 18.14 Seal Block Name Range ---------- ---------------- Seal U+3D000..U+3FC3F The Small Seal Script (小篆) originates from the script standardization (Shutongwen, 書同文) by the Qin Dynasty (秦朝), 221-207 BCE. This repertoire is the unified encoding of the primary dictionary of the Small Seal script, _Shuowen Jiezi_ (説文解字, SWJZ), which Xu Shen (許慎) in the Eastern Han dynasty (東漢朝) completed around 100 CE. Although the glyphs in _Shuowen Jiezi_ are not precisely identical to excavated Qin materials due to historical layering, its text coverage and historical usage remain stable; it continues to be referred to when discussing the traditional glyph shapes of modern Hanzi, or when collating Old Hanzi characters collected from excavated pre-Qin materials. ## Shuowen Jiezi, Source of "Small Seal" in the Unicode and its Content Presented to the court in 121 CE, SWJZ referred to the Small Seal script to analyze the relationships among glyph shapes, pronunciations, and meanings, making it the foundational reference material for the script. Apart from the Small Seal script, SWJZ includes pre-Qin variant scripts to encompass earlier and non-Qin historical traditions: "Guwen" (古文, about 470 glyphs), representing regional variants used outside the Qin domain (traditionally ascribed to the six major eastern states, or 東方六國文字), and "Zhouwen" (籀文, about 200 glyphs), derived from the Western Zhou dynasty (西周朝) and often treated as synonymous with the "Large Seal" (大篆). Smaller variant categories include "alternative forms" (或體) and "strange forms" (奇字). According to Xu Shen's original postface, the dictionary recorded 9,353 primary entries, called _Zhengwen_ (正文, headword glyphs), and 1,163 variants, called _Chongwen_ (重文, additional glyphs). Because the vast majority of the Zhengwen entries are presented in the Small Seal script, they are also referred to as _Zhengzhuan_ (正篆) in later philological commentaries. While Zhengwen usually represents the Small Seal and Chongwen preserves pre-Qin variants, exceptions exist where a Guwen or Zhouwen glyph serves as the Zhengwen. In the standard block-printing style of the dictionary, characters appearing as Zhengwen are uniformly rendered in the standard block-printing style, even if they originate from pre-Qin scripts like Guwen or Zhouwen. ## Texts of Shuowen Jiezi, Used for the Unicode Code Chart ### Daxu Ben (THX, CCZ columns) The standard text of SWJZ is the emended text by Xu Xuan (徐鉉) in 986 CE during the Northern Song dynasty (北宋朝), traditionally referred to as the "Daxu Ben" (大徐本). Xu Xuan systematically regularized the accumulated textual variations from the Tang dynasty, establishing the definitive structural and graphical framework of the dictionary that has served as the de facto standard for centuries. Xu Xuan introduced two categories of new entries not counted in the original text: 19 entries called *Xinxiuzi* (新修字), which maintain consistency within SWJZ, and 420 entries called *Xinfuzi* (新附字), which accommodate characters found in pre-Qin canonical texts but omitted from the original SWJZ. Traditionally, the Daxu Ben integrates the 19 *Xinxiuzi* entries directly into the _Zhengwen_. On the other hand, the 420 *Xinfuzi* entries are separately appended at the end of each radical. The Unicode Standard preserves this historical handling of *Xinxiuzi* and *Xinfuzi*. The Unicode code chart utilizes two woodblock reprints of the Daxu Ben: the Tenghuaxie version (藤花榭本, THX) and the reprint by Chen Changzhi (陳昌治本, CCZ). The THX version preserved the original layout, while the CCZ reprint adjusted line breaks. The source of CCZ was the Pingjinguan version (平津館本, PJG) by Sun Xingyan (孫星衍). Due to its high practicality and widespread accessibility in modern publishing, the CCZ reprint—which applied various corrections to its PJG source—was prioritized for inclusion as a distinct column. Both THX and CCZ applied various corrections to their sources independently. Consequently, their results diverged from the same Song print. ### Xiaoxu Ben (QJZ column) The "Xiaoxu Ben" (小徐本) refers to the "Shuowen Jiezi Xizhuan" (說文解字繫傳) by Xu Kai (徐鍇), who passed away in 974 CE during the Southern Tang dynasty (南唐朝). No complete Song-period printed editions survive; the text is known through manuscripts from the Ming and Qing periods, and woodblock reprints based on them. The Unicode code chart shows the glyphs from the reprint by Qi Junzhao (祁寯藻本, QJZ), which preserves the most complete text. Due to later transmissions, some glyphs are inferred to have been aligned with the Daxu Ben, and some *Xinxiuzi* entries were imported from it, though many distinct variations remain. ### Duan Zhu Ben (DYC column) Duan Yucai completed detailed annotations and emendations to the Daxu Ben in 1815 CE, titled "Shuowen Jiezi Zhu" (說文解字注). Duan applied extensive corrections to the glyph shapes and descriptions based on his own philological analyses. Consequently, when a glyph shape in the Duan Zhu text diverges significantly from the Daxu Ben or Xiaoxu Ben, the Unicode Standard encodes it under a separate code point (even if it shares the same meaning and pronunciation) to faithfully represent Duan's specific philological reconstructions. ## Structure and Encoding Principles. The Unicode Standard for Seal is based on four different versions of _Shuowen Jiezi_, presented in a four-column layout. Two columns correspond to _Daxu Ben_ (represented by the THX and CCZ columns respectively), one column corresponds to the _Xiaoxu Ben_ (QJZ column), and one column corresponds to the _Duan Zhu_ (DYC column). The repertoire and ordering are primarily based on the Tenghuaxie (THX) version, with the Seal glyphs from the other three versions arranged according to the ordering of the THX version. Three versions use a purely numeric referencing convention for their sources, while THX distinguishes its newly added *Xinfuzi* content using a different index prefixed by 'X'. However, no such prefix is used for the Xinxiuzi in the THX column, because the Daxu Ben traditionally did not distinguish between the _Zhengwen_ and *Xinxiuzi* in the collations. The characters are grouped into 540 subclasses based on their common radical. Any extensions are always added at the end of the appropriate radical class. While the CCZ, QJZ and DYC columns contain these extensions, they are numbered sequentially. Furthermore, because the THX source is considered the primary source, it also contains elements of the other sources originally not present in THX. Those additional elements use indexes prefixed by 'Y'. ## Character Names. The names for the Seal characters are algorithmically derived by prefixing the code point with the string "SEAL CHARACTER-". Hence the name for U+3D000 is SEAL CHARACTER-3D000. ## Code Point Order. The characters are arranged in sequence, grouped into 540 subclasses, according to their radicals. The 540 radicals summarized in _Shuowen Jiezi_ cover all forms and meanings of Chinese characters and are called structural radicals; their values are theoretical. They are identified in the Seal repertoire by being the first element of each group using the radical as a classifier. Within each group, characters are ordered following their sequences in the original material from the Tenghuaxie (THX) version. Other source elements not originally present in THX are inserted in the overall sequence according to their original location in their respective sources. Unlike modern Hanzi, the sequencing of Seal characters does not use a concept of stroke count. ## Glyphs. In historical traditions, Small Seal characters are distinctively elongated and rendered within a vertical rectangular framework rather than a perfect square. In modern digital typography and block-printing practices, however, Seal characters are typically treated as monospaced, similarly to modern Hanzi ideographs. Each character is allocated a uniform width and height, resulting in a consistent rectangular cell regardless of the structural complexity of its particular form. This practice adapts the ancient script to the modern typographical convention of forcing characters into standardized advance widths, allowing Seal characters to be integrated into running text alongside modern Hanzi. ## Correspondence with Modern Hanzi Ideographs. Each Seal character is associated with a modern Hanzi (CJK Unified) ideograph. That relationship is not one-to-one: multiple Seal characters may be associated with the same modern Hanzi ideograph. In contrast, while it is possible to associate a Seal character with multiple modern Hanzi ideographs, the current definition in the Unicode Character Database uses a single value per Seal character. Note that this mapping is based on choosing the modern CJK Unified Ideograph that best represents the specific glyph shape or historical identification of each Seal entry to facilitate typographical indexing and recognition. It is explicitly designed for reference purposes and does not constitute a reversible dictionary or a contextual conversion table for algorithmically translating modern Hanzi text into the historical Small Seal script. ## Source Data. The Unicode Character Database contains a source data file for Seal called SealSources.txt. This data file contains normative information on the source references for each Seal character. SealSources.txt also contains a modern Hanzi value (kSEAL_MCJK) and one or more radical values (kSEAL_Rad) for each Seal character. The kSEAL_Rad property defines a radical entry as a radical number followed by a dot and its encoded value. In rare cases where a character philologically belongs to multiple radicals, the property contains multiple space-separated radical values. ## Duplicated Entries. In some cases, the original _Shuowen Jiezi_ lists the exact same character under multiple different radicals with identical analytical descriptions and no graphical distinction (e.g., "𠮢" appearing in both the "口" radical and the "又" radical). To prevent duplicate encoding, the Unicode Standard encodes such characters only once, omitting the redundant duplicate entries from the repertoire. Consequently, these deliberate omissions result in gaps (skips) in the sequential source indexes within the code chart. For example, the Small Seal character of "𠮢" is coded at U+3D3DD (TH-00939, C-00972, K-00945, D-00934), the code position is located under the radical "口." As defined in SealSources.txt, the kSEAL_Rad property for U+3D3DD has multiple space-separated values: "22.3D374" and "76.3D888". The former "22.3D374" is for the 22nd radical corresponding to "口", and "76.3D888" is for the 76th radical corresponding to "又". It indicates that this character was duplicated in SWJZ. TH-02078, C-02157, K-02083, D-02061 are missing in the code chart, they correspond to the position of the duplicated "𠮢" appearing under the radical "又".
Date/Time: Mon July 06 20:03:58 PT 2026
ReportID: ID20260706200358
Name: Peter Constable
Report Type: Public Review Issue
Opt Subject: PRI 548: U18 Beta: NR 2 and Egyptian Hieroglyphs [EDC]
In the core spec, section 4.8.1, Table 4-8 is introduced as follows: "The exact ranges subject to name derivation rules NR1 and NR2, and the specified prefix strings are summarized in Table 4-8." NR1 pertains specifically to Hangul; hence, all other algorithmic names covered in Table 4-8 appear to be covered by NR2. But NR2 limits its scope to characters with the property Ideographic. The problem is that Egyptian Hieroglyph characters are necessarily covered in Table 4-8 but are not Ideographic. Hence, there is a gap: no name rule currently covers Egyptian Hieroglyphs.
Date/Time: Mon July 06 21:09:43 PT 2026
ReportID: ID20260706210943
Name: suzuki toshiya
Report Type: Public Review Issue
Opt Subject: PRI 548: Enhancement for SealSources.txt [CJK]
Dear UTC experts, I want to propose an enhancement to SealSources.txt documenting duplicated-and-unencoded source references in Seal. Currently, SealSources.txt does not explicitly provide information on which specific duplicated entries from the original Shuowen Jiezi (SWJZ) sources were omitted from the Unicode code chart to prevent duplicate encoding. While there is no need to modify the code chart itself, implementers and researchers frequently need to track exactly which historical source entries (e.g., from the THX, CCZ, QJZ, or DYC editions) were identified as duplicates and consequently dropped from the repertoire. Although the multi-valued kSEAL_Rad property serves as an initial indicator that a given code point corresponds to multiple radicals in SWJZ, it does not specify the precise structural locations or source indexes of the omitted duplicate entries. Providing this missing source -reference data—either as an informative note in the text or as a complementary data field—would significantly enhance the traceability and utility of the Seal dataset. For example, current SealSources.txt gives some properties to U+3D3DD, like: U+3D3DD kSEAL_THXSrc TH-00939 U+3D3DD kSEAL_CCZSrc C-00972 U+3D3DD kSEAL_QJZSrc K-00945 U+3D3DD kSEAL_DYCSrc D-00934 U+3D3DD kSEAL_MCJK 20BA2 U+3D3DD kSEAL_Rad 22.3D374 76.3D888 Here, U+3D3DD is a character encoding TH-00939, C-00971, etc under the radical 23.3D374, and it unifies another entry under the radical 74.3D888. But it is hard to identify which SWJZ entry was omitted. I propose to add something like: U+3D3DD kSEAL_DupSrc TH-02078 C-02157 K-02083 D-02061 Regards, suzuki toshiya
Date/Time: Mon Jul 20 14:00:46 PDT 2026
ReportID: ID20260720140046
Name: Philippe Verdy
Report Type: Public Review Issue
Opt Subject: PRI 548: U+1DB16 name "BARS" (plural) [CHARTS]
There's a typo in the proposed character name (in the new block https://www.unicode.org/charts/PDF/Unicode-18.0/U180-1DB00.pdf pending for Unicode 18.0), there's a missing plural (these are two separate orthogonal bars, intersecting in the middle, this is not a single bar going in two directions): U+1DB16 LEIBNIZIAN CONGRUENCE-2 WITH HORIZONTAL AND VERTICAL BAR should be: U+1DB16 LEIBNIZIAN CONGRUENCE-2 WITH HORIZONTAL AND VERTICAL BARS The same is true in the English namelist.txt file (part of the UCD). This should be fixed (at least in English) when synchronizing both standards, at least in the final document that will be voted soon by ISO WG2, or by sending an errata notification to their next meeting. As for now we don't have the French namelist for ISO/IEC 10646, whose translation is probably ongoing (but can't be reviewed for now), I suggest that the namelist in French (needed for ISO WG2) be reviewed (or open to submissions) during the review process (initially it could be translated semi-automatically before or during the alpha review, but should be informally vetted during the beta public review). However, this may be delayed until the next released update of ISO/IEC 10646 (which also still has not been published for Unicode 17.0 since more than one year, not even in English; I think that the WG2 has accepted longer schedules, even if the ISO WG2 coordinates with the UTC by their votes). As well the ISO WG2 would have less work to do for that French translation that they'll publish later in their next published update of ISO/IEC 10646 But may be you'll allow translating and vetting the French namelist after Unicode 18.0 release, in the next CLDR submission period.