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 [CHARTS]
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).