The sections below contain links to permanent feedback documents for the open Public Review Issues as well as other public feedback as of January 5, 2023, since the previous cumulative document was issued prior to UTC #173 (October 2022).
The links below go directly to open PRIs and to feedback documents for them, as of January 5, 2023.
The links below go to locations in this document for feedback.
Feedback routed to CJK & Unihan Group for evaluation [CJK]
Feedback routed to Script ad hoc for evaluation [SAH]
Feedback routed to Properties & Algorithms Group for evaluation [PAG]
Feedback routed to Emoji SC for evaluation [ESC]
Feedback routed to Editorial Committee for evaluation [EDC]
Other Reports
Date/Time: Mon Nov 21 07:03:04 CST 2022
Name: Andrew West
Report Type: Other Document Submission
Opt Subject: Unihan_IRGSources.txt (15.0)
U+3032E (⿰山孫) is indexed under 子 39.10, which is not intuitive. To aid discoverability please add a secondary index under 山 46.10.
Date/Time: Sun Dec 4 07:35:47 CST 2022
Name: Ken Lunde
Report Type: Error Report
Opt Subject: Unihan_OtherMappings.txt
In order to synchronize the provisional kKSC0 and kKSC1 properties with the corresponding source prefixes of the normative kIRG_KSource property, the following kKSC0 and kKSC1 property values should be removed: U+F92C kKSC0 5011 U+F9B8 kKSC0 7170 U+8C6C kKSC1 7575 They should be replaced with the following new kKSC0 and kKSC1 property values: U+FA2E kKSC0 5011 U+FA2F kKSC0 7170 U+27CEF kKSC1 7575 The two kKSC0 property values became out-of-sync with the corresponding K0 source prefix property values from Unicode Version 6.0 (2010), and the kKSC1 property value became out-of-sync with the corresponding K1 source prefix property value from Unicode Version 13.0 (2020). Another alternative is to consider removing the two provisional properties altogether, given that they are intended to be synchronized with the kIRG_KSource property values that are associated with the K0 and K1 source prefixes, respectively. The only difference is that kKSC0 and kKSC1 properties specify decimal Row-Cell (aka ku/ten) values, and the K0 and K1 source prefixes specify the corresponding hexadecimal values.
Date/Time: Sun Dec 4 08:06:30 CST 2022
Name: Ken Lunde
Report Type: Error Report
Opt Subject: Unihan_OtherMappings.txt
In order to synchronize the provisional kHKSCS property with the corresponding source prefix of the normative kIRG_HSource property, H, the following kHKSCS property values should be removed: U+3D1D kHKSCS 91B5 U+4CA4 kHKSCS 9D73 U+2F9B2 kHKSCS 8FA8 They should be replaced with the following new kHKSCS property values (note the ordering difference): U+9FD0 kHKSCS 9D73 U+270F0 kHKSCS 8FA8 U+2A3ED kHKSCS 91B5 The first and second kHKSCS property values became out-of-sync with the corresponding H source prefix property values from Unicode Version 8.0 (2015), and the third kHKSCS property value became out-of-sync with the corresponding H source prefix property value from Unicode Version 11.0 (2018). Another alternative is to consider removing the provisional kHKSCS property altogether, given that it is intended to be synchronized with the kIRG_HSource property values that are associated with the H source prefix. The only difference in their property values is the "H-" source prefix.
Date/Time: Sun Dec 4 12:00:37 CST 2022
Name: Ken Lunde
Report Type: Error Report
Opt Subject: Unihan_OtherMappings.txt
In order to synchronize the provisional kKPS1 property with the corresponding source prefix of the normative kIRG_KPSource property, KP1, the following 12 kKPS1 property values should be removed: U+48D4 kKPS1 7E68 U+20ED4 kKPS1 3A79 U+23D3C kKPS1 5177 U+2435C kKPS1 5604 U+25864 kKPS1 628E U+25F0A kKPS1 662C U+27262 kKPS1 7164 U+2779A kKPS1 749F U+27AAC kKPS1 7755 U+28418 kKPS1 7D1B U+28D4E kKPS1 8282 U+2A50C kKPS1 9186 They should be replaced with the following 188 new kKPS1 property values that include 12 that replace those listed above: U+3E14 kKPS1 5DC7 U+431B kKPS1 7755 U+56D8 kKPS1 3749 U+6B76 kKPS1 61A9 U+7AD0 kKPS1 636D U+9FC3 kKPS1 5E2B U+F936 kKPS1 70DC U+FA70 kKPS1 341D U+FA71 kKPS1 347E U+FA72 kKPS1 34D0 U+FA73 kKPS1 35DE U+FA74 kKPS1 3714 U+FA75 kKPS1 3740 U+FA76 kKPS1 383E U+FA77 kKPS1 3862 U+FA78 kKPS1 39E5 U+FA79 kKPS1 39EF U+FA7A kKPS1 3A42 U+FA7B kKPS1 3A48 U+FA7C kKPS1 3BEE U+FA7D kKPS1 3C51 U+FA7E kKPS1 3CAF U+FA7F kKPS1 3CB2 U+FA80 kKPS1 3D45 U+FA81 kKPS1 3DFC U+FA82 kKPS1 414E U+FA83 kKPS1 416B U+FA84 kKPS1 41FB U+FA85 kKPS1 4244 U+FA86 kKPS1 4348 U+FA87 kKPS1 437E U+FA88 kKPS1 4399 U+FA89 kKPS1 43FF U+FA8A kKPS1 4410 U+FA8B kKPS1 4486 U+FA8C kKPS1 4505 U+FA8D kKPS1 469B U+FA8E kKPS1 46C4 U+FA8F kKPS1 46F9 U+FA90 kKPS1 480E U+FA91 kKPS1 4994 U+FA92 kKPS1 4A42 U+FA93 kKPS1 4A4B U+FA94 kKPS1 4ABD U+FA95 kKPS1 4F27 U+FA96 kKPS1 4FA9 U+FA97 kKPS1 5128 U+FA98 kKPS1 5281 U+FA99 kKPS1 52B4 U+FA9A kKPS1 5336 U+FA9B kKPS1 53FA U+FA9C kKPS1 5559 U+FA9D kKPS1 561F U+FA9E kKPS1 5678 U+FA9F kKPS1 5786 U+FAA0 kKPS1 57FE U+FAA1 kKPS1 597A U+FAA2 kKPS1 5A5D U+FAA3 kKPS1 5ABB U+FAA4 kKPS1 5BF5 U+FAA5 kKPS1 5BF9 U+FAA6 kKPS1 5D48 U+FAA7 kKPS1 5D5C U+FAA8 kKPS1 5D91 U+FAA9 kKPS1 5DF3 U+FAAA kKPS1 5E08 U+FAAB kKPS1 6083 U+FAAC kKPS1 6330 U+FAAD kKPS1 6435 U+FAAE kKPS1 659F U+FAAF kKPS1 66BA U+FAB0 kKPS1 671B U+FAB1 kKPS1 6873 U+FAB2 kKPS1 69B1 U+FAB3 kKPS1 6DBB U+FAB4 kKPS1 6E6C U+FAB5 kKPS1 7250 U+FAB6 kKPS1 7451 U+FAB7 kKPS1 74C8 U+FAB8 kKPS1 74D4 U+FAB9 kKPS1 769A U+FABA kKPS1 769E U+FABB kKPS1 76A4 U+FABC kKPS1 76B3 U+FABD kKPS1 76C2 U+FABE kKPS1 76F1 U+FABF kKPS1 76FD U+FAC0 kKPS1 77CB U+FAC1 kKPS1 7976 U+FAC2 kKPS1 7CAE U+FAC3 kKPS1 7DF1 U+FAC4 kKPS1 7F3E U+FAC5 kKPS1 80CE U+FAC6 kKPS1 8340 U+FAC7 kKPS1 8404 U+FAC8 kKPS1 84E4 U+FAC9 kKPS1 862D U+FACA kKPS1 866A U+FACB kKPS1 869A U+FACC kKPS1 8705 U+FACD kKPS1 8BAB U+FACE kKPS1 927F U+FACF kKPS1 441C U+FAD0 kKPS1 443E U+FAD1 kKPS1 4B26 U+FAD2 kKPS1 4CE2 U+FAD3 kKPS1 5DF6 U+FAD5 kKPS1 5EBB U+FAD6 kKPS1 654F U+FAD7 kKPS1 7A0A U+FAD8 kKPS1 91E5 U+FAD9 kKPS1 9273 U+20617 kKPS1 49E2 U+20F25 kKPS1 3A79 U+20F96 kKPS1 3AA3 U+214A1 kKPS1 9186 U+2258D kKPS1 7352 U+23D1F kKPS1 5177 U+243DF kKPS1 5604 U+24454 kKPS1 5642 U+24662 kKPS1 5717 U+24AF4 kKPS1 59FC U+2564A kKPS1 6134 U+25871 kKPS1 628E U+25F45 kKPS1 662C U+27261 kKPS1 7164 U+27762 kKPS1 749F U+28416 kKPS1 7D1B U+286CD kKPS1 7E68 U+28D64 kKPS1 8282 U+2ABAB kKPS1 4731 U+2ABE9 kKPS1 487E U+2B0DC kKPS1 6651 U+2B0EF kKPS1 672B U+2B0F5 kKPS1 6752 U+2B29B kKPS1 70BE U+2B2AB kKPS1 712E U+2B2FE kKPS1 73E1 U+2F804 kKPS1 34EE U+2F805 kKPS1 3534 U+2F833 kKPS1 38CF U+2F835 kKPS1 54B7 U+2F84C kKPS1 3A92 U+2F84F kKPS1 3AD2 U+2F852 kKPS1 3BAF U+2F855 kKPS1 3BD5 U+2F887 kKPS1 40D3 U+2F88B kKPS1 412C U+2F899 kKPS1 41F8 U+2F8A0 kKPS1 42C8 U+2F8A6 kKPS1 43C1 U+2F8A7 kKPS1 43D2 U+2F8AD kKPS1 4462 U+2F8B1 kKPS1 44A4 U+2F8B4 kKPS1 4539 U+2F8B7 kKPS1 45D5 U+2F8BA kKPS1 462A U+2F8D0 kKPS1 49C3 U+2F8E0 kKPS1 4B46 U+2F8E1 kKPS1 4B5D U+2F8E2 kKPS1 4B57 U+2F8E5 kKPS1 4BF7 U+2F8E6 kKPS1 4C6C U+2F8FE kKPS1 511E U+2F900 kKPS1 5145 U+2F901 kKPS1 5150 U+2F907 kKPS1 51C4 U+2F912 kKPS1 53B8 U+2F922 kKPS1 56A8 U+2F926 kKPS1 57D0 U+2F938 kKPS1 5AF0 U+2F94E kKPS1 6043 U+2F959 kKPS1 6246 U+2F95F kKPS1 639A U+2F96C kKPS1 6725 U+2F99F kKPS1 6E4B U+2F9B8 kKPS1 7168 U+2F9BA kKPS1 71CD U+2F9D3 kKPS1 78AC U+2F9DB kKPS1 7AAD U+2F9DC kKPS1 7B04 U+2F9E8 kKPS1 8054 U+2F9EA kKPS1 80AD U+2F9EE kKPS1 8255 U+2FA00 kKPS1 8703 U+2FA0D kKPS1 8E7E U+2FA1B kKPS1 9190 U+31C2D kKPS1 5AC6 In terms of the 12 kKPS1 property value mapping changes, the first one became out-of-sync with the corresponding KP1 source prefix property values from Unicode Version 3.2 (2002), and the remaining 11 became out-of-sync with the corresponding KP1 source prefix property values from Unicode Version 5.2 (2009). Another alternative is to consider removing the two provisional properties, kKPS0 and kKPS1, altogether, given that they are intended to be synchronized with the kIRG_KPSource property values that are associated with the KP0 and KP1 source prefixes, respectively. The only difference in their property values is the "KP0-" or "KP1-" source prefixes.
Date/Time: Sun Dec 18 08:34:02 CST 2022
Name: Ken Lunde
Report Type: Error Report
Opt Subject: CJKRadicals.txt
The following entry is missing from the UCD's CJKRadicals.txt data file: 148'; 2EC6; 89D2 It is the Chinese simplified form of Radical 148.
Date/Time: Sun Dec 25 19:10:34 CST 2022
Name: Paul Masson
Report Type: Error Report
Opt Subject: kPhonetic for U+645E
This character appears on p.350 of Casey but is not in a phonetic group. It appears that the appropriate one is 842, if you want to add this to the database. Thank you.
Date/Time: Tue Dec 27 19:01:03 CST 2022
Name: Eiso Chan
Report Type: Other Document Submission
Opt Subject: Change the fields for UTC-02994 in UAX #45 and kTotalStrokes for U+44D5
WS2017-04302:UTC-02994 is a postponed character now. I found more evidence on it to show it is not the typesetting error, and the new evidence shows it is the variant of 䓕 (U+44D5) without any doubt. Please see https://hc.jsecs.org/irg/ws2017/app/?id=04302 . IRG has adopted new unification rules that deal with differences of structure, so it is acceptable to unify this character with 䓕 (U+44D5). The Status field for this character in UAX #45 should be changed to ExtA as below for the possible horizontal extension in future. On the other hand, we should also add 162.8 as the second RS of 䓕 (U+44D5), because the original RS is also reasonable for UTC-02994 based on the new evidence. For the General comments field, the kMandarin property value for 䓕 (U+44D5) has been assigned and useful for the comment Chinese use, and the Putonghua value as yuǎn is just only used for the use in Guangdong, Guangxi, Hong Kong and Macao, so it is better to remove the first letter k. The current kCantonese property is suitable for UTC-02994 as well. UTC-02994;ExtA;U+44D5;140.8 162.8;;⿺辶芫;UTCDoc L2/17-062 14;Mandarin: yuǎn;12 10;1 The current kTotalStrokes for 䓕 (U+44D5) is 14, that is not right. It is better to change it to 12 to match the newest rule.
Date/Time: Tue Dec 6 09:54:11 CST 2022
Name: Jaycee Carter
Report Type: Error Report
Opt Subject: Unihan_DictionaryIndices.txt
The following additions and changes to the Unihan kKangXi values appear to be possible, based on the scanned text of the Kangxi dictionary available at https://www.kangxizidian.com/: U+34D8: 0134.290 (compare source glyphs T5-3129 & UTC-00639) U+385B: 0335.010 (compare source glyph T4-3D29) U+3CC7: 0612.120 (compare source glyph T6-284A; appears to be unifiable by UCV #235) U+4945: 0735.130 1318.220 U+4A36: 1377.190 U+4DB9: 0304.130 U+4DBA: 0504.310 U+4DBB: 0505.010 U+4DBC: 0506.140 U+5173: 0127.070 0879.050 (compare source glyph T4-2234) U+537C: 0159.290 (compare source glyphs HB2-CDF5 & T2-2937) U+67D0: 0519.010 0528.090 U+67F5: 0521.070 U+6F5B: 0649.090 U+7D01: 0915.140 (compare source glyphs HB2-D04C & T2-2C6D; appears to be unifiable by UCV #46) U+8275: 1014.110 (appears to be unifiable by UCV #181) U+8286: 1018.030 (compare source glyph T3-2728; appears to be unifiable by UCV #152 & #235) U+833E: 1029.160 (compare source glyph T3-2A5F; appears to be unifiable by UCV #180) U+84F1: 1052.220 (compare source glyphs HB2-DFA9 & T2-464E and compatibility ideograph U+2F9A8; appears to be unifiable by UCV #181) U+20020: 0887.260 (appears to be unifiable similarly to UCV #303) U+200CA: 1362.170 U+200CB: 0976.090 U+201DD: 0141.130 U+2028B: 1536.370 U+209C8: 0473.100 U+209E7: 1128.110 U+20A1D: 0382.030 U+20A81: 0794.220 U+20AA5: 0162.040 U+20B46: 0101.070 U+2174F: 0272.390 U+21D13: 0381.070 U+21D4F: 0295.040 U+21DA2: 0615.020 U+2215B: 1536.360 (appears to be unifiable by UCV #62) U+221CF: 0342.180 0362.280 (compare source glyph T6-5C4E) U+22597: 0872.030 U+22FF9: 0585.140 (compare source glyph T7-2351) U+23184: 1355.180 U+231F6: 0611.130 U+23353: 0331.140 U+2363B: 0547.100 (appears to be unifiable by UCV #152) U+23C9D: 0131.250 U+23E27: 0632.020 (appears to be unifiable by UCV #222) U+24548: 0409.100 (appears to be unifiable by UCV #36) U+24A61: 0744.190 U+253EC: 0192.140 0825.160 U+257A9: 0855.240 (appears to be unifiable by UCV #181) U+257DF: 0859.080 U+2627D: 0946.220 U+26B12: 1018.050 (appears to be unifiable by UCV #152) U+26FB1: 1063.110 1070.150 (compare source glyph T4-5D25; appears to be unifiable by UCV #174) U+2845F: 0456.100 (appears to be unifiable by UCV #245) U+2865E: 1265.060 U+28EEA: 1354.080 (compare source glyph T7-3D33) U+29272: 1526.020 U+2A594: 1530.100 (final stroke difficult to make out in copy) U+2AEC5: 0714.190 U+2E4D6: 1072.400 (no Chinese source given in Unihan, but appears to be an exact match) U+31C2D: 0760.040 (compare compatibility ideograph U+2F936) Additionally, please consider the following changes: U+23551: 0539.240 0542.170 (appears potentially unifiable, as no semantic difference) U+26400: 1008.170 (presumably unifiable; compare 羽 U+7FBD, source glyph K0-6962) U+29692: 1416.220 (final stroke appears to be missing in copy, appearing identical to 䬢 (U+4B22; kKangXi 1416.050); however, context suggests this character is intended; if so, left radical appears to be unifiable by UCV #358) Many thanks.
Date/Time: Tue Dec 6 07:20:49 CST 2022
Name: Charlotte Buff
Report Type: Other Document Submission
Opt Subject: L2/21-235R: Issues concerning two legacy computing characters
Regarding the “Symbols for Legacy Computing Supplement” repertoire that is slated for release in a future version of the standard: • Is the proposed U+1CDB7 BLOCK OCTANT-3478 unifiable with existing U+1FB97 HEAVY HORIZONTAL FILL? U+1FB97 is annotated with the alias “upper middle and lower one quarter block”, which is the same block arrangement that results from octants 3, 4, 7, and 8 being set. • Is the name LARGE TYPE PIECE RAISED UPPER RIGHT ARC for U+1CE35 correct? Looking at the other “upper arc” pieces (U+1CE1A and U+1CE24), shouldn’t its name be LARGE TYPE PIECE RAISED UPPER *LEFT* ARC instead?
Date/Time: Thu Nov 10 06:14:10 CST 2022
Name: Tomasz Gucio
Report Type: Error Report
Opt Subject: LineBreakTest.txt
Hello, I've found what might be an error in the latest line break test file. In the case below, the expected result is no break between the two code points based on the first code's property (Other). However, this and other codes in the range are Ideographic (ID) and so line break should be allowed. Property data: LineBreak-15.0.0.txt, Date: 2022-07-28, 09:20:42 GMT [KW, LI] 1F02C..1F02F;ID # Cn [4] <reserved-1F02C>..<reserved-1F02F> Test case: LineBreakTest-15.0.0.txt, Date: 2022-02-26, 00:38:39 GMT × 1F02C × 1F3FF ÷ # × [0.3] <reserved-1F02C> (Other) × [30.22] EMOJI MODIFIER FITZPATRICK TYPE-6 (EM) ÷ [0.3] Best regards, Tomasz
Date/Time: Mon Dec 5 17:34:03 CST 2022
Name: David Eugene Starner
Report Type: Public Review Issue
Opt Subject: 466
"""void zero(double** matrix, int rows, int columns) {
for (int i = 0; i < rows; ++i) {
double* row = matrix[i];
for (int і = 0; і < columns; ++і) {
row[i] = 0.0;
}
}
}
This program looks like it zeros a rows by columns rectangle, but it actually only
zeros a diagonal, because the identifier і on line 4 is a Cyrillic letter, whereas
i is the Latin letter everywhere else."""
That program looks like it goes into an infinite loop if rows > columns, as the
inner loop index overwrites the outer one. It's bad code whether or not the identifier
on line 4 is Latin or Cyrillic.
Date/Time: Wed Dec 14 10:54:46 CST 2022
Name: Steven Pemberton
Report Type: Error Report
Opt Subject:
Character classes of U+2126 OHM SIGN and U+00B5 MICRO SIGN Programming languages and other software systems using Unicode generate functions directly from the Unicode database, for instance functions to convert strings to uppercase, lowercase and titlecase. For instance, CSS, which has a text-transform property. If I take the text "Resistance is 950µΩ" and apply the different transforms, I get displayed: text-transform: uppercase: RESISTANCE IS 950ΜΩ text-transform: lowercase: resistance is 950µω text-transform: capitalize: Resistance Is 950µΩ This is clearly unacceptable, since it changes the meaning of the text. To fix this, U+2126 OHM SIGN and U+00B5 MICRO SIGN should be classified as "Symbol, Other", and not be assigned case equivalents. Respectfully, Steven Pemberton
Date/Time: Thu Jan 5 20:53:39 CST 2023
Name: NAKAUCHI Tomohiro
Report Type: Error Report
Opt Subject: UTR#36 Unicode Security Considerations
I've read UTR#36-rev.15 interestedly. At that time, I found some errors. So, I would like to report those: 1. I have a question that in line 619 to 625 why such structure(html) is used? (which invokes that the tool tip shows 'U+0906 DEVANAGARI LETTER AA' in my web browser.) I think that description of 'title' attribute used in span element is inappropriate. 2. In addition, at the same parahraph, description says that 'look identical (ẋ̣ and ẋ̣̇)', but my web browser shows that the former is <x, dot_below, dot_above> and the latter is <x, dot_below, dot_above, dot_above>. So, I think that these are not identical. 3. In line 1393, word 'such as' is duplicated. 4. In section 2.7 Numeric Spoofs, I think that description is slightly incorrect. Although string appeared like "89" is represented by Bengali and Oriya, this description says that is only 'the Bengali string "৪୨"'. 5. In line 1628, text written is 'Final_Sigma as provided in Table 3-15'. I guess that this is 'Table 3-17'. 6. In line 3044, word 'from' is duplicated.
Date/Time: Tue Jan 3 07:25:57 CST 2023
Name: Sneha Raman
Report Type: Other Question
Opt Subject: Emoji Inclusivity
Hello! We are Passion.io,and big on using Slack emojis for welcoming our new joiners,celebrating promotions, etc. However, in the spirit of diversity and inclusion, Iwould like to bring to your attention the terminology of the superhero emojis, and Slack mentioned that they pull the emojis from Unicode, and don't have control over naming: :superhero: :skin-tone-4: - this is ""superhero" :female_superhero ::skin-tone-3:- this is "female_superhero" We feel the first emoji can be termed male_superhero,or name the second one "superheroine". It's 2023,and this is about being equal and inclusive. It's all in the details. Thank you. - Sneha.
Date/Time: Sat Nov 26 01:33:30 CST 2022
Name: Kushim Jiang
Report Type: Website Problem
Opt Subject: Unicode Terminology English - Simplified Chinese
Here are the suggestions. (1) Accent Mark 重音标记. Consider modifying to 变音标记 because its function is “to alter the phonetic value”. (2) Binary File 二进制档案. Consider modifying to 二进制文件 according to [1] “文件 file”. (3) BNF (Backus-Naur Form) 巴克斯诺尔范式. Consider modifying to 巴克斯-诺尔范式 according to [1] “巴克斯-诺尔范式 Backus-Naur form，BNF”. (4) BOM (Byte Order Mark) 字节排序标记. Consider modifying to 字节次序标记 according to [1] “大端 big-endian, 一种在内存中存放多字节数据时的字节存放次序”. (5) Block 字区. Consider modifying to 字符块 according to the Unicode Terminology itself “Character Block 字符块”. (6) Character Sequence 字符顺序, Composite Character Sequence 复合字符顺序. Consider modifying to 字符序列 and 复合字符序列 according to the meaning “an ordered sequence of character(s)”. (7) Code Unit 码单位, Code Value 码值. Consider modifying to 码元 (code element in digital communication field) as code value is an “obsolete synonym for code unit”. (8) Combining Character 组合字符, Combining Character Sequence 组合字符序列, Combining Class 组合类别. Consider modifying to 结合字符, 结合字符序列 and 结合类别 to emphasize the unequal relationship between base and mark. (9) Compatibility Equivalent 兼容等值. Consider modifying to 兼容等价 according to the Unicode Terminology itself “Equivalence 等价”. (10) EBCDIC (Extended Binary-Coded Decimal Interchange Code) 延伸二进制编码的十进制交换码, ECCS (Extended Combining Character Sequence) 延伸组合字符序列, MIME (Multipurpose Internet Mail Extensions) 多功能互联网邮件延伸定义. Consider modifying to 扩展二进制编码的十进制交换码, 扩展结合字符序列 and 多功能互联网邮件扩展. (11) Encoded Character 已编码字符. Consider modifying to 编码字符 according to the Unicode Terminology itself “Coded Character 编码字符, see encoded character.” (12) Extended Base 延伸基. Consider modifying to 扩展基本字符. (13) Higher-Level Protocol 高级规约. Consider modifying to 高层协议 according to [1] “协议 protocol” and “规约 specification”. (14) Modifier Letter 改形字母. Consider modifying to 修饰字母 as it does not change the shape of the previous letter or the letter itself. (15) Paragraph Embedding Level 段落内置层级. Consider modifying to 段落嵌入层级 according to the Unicode Terminology itself “Embedding 嵌入”. (16) Presentation Form 表达模式. Consider modifying to 显现形式. (17) Rich Text 加工文本. Consider modifying to 富文本 according to the Unicode Terminology itself “Fancy Text 富文本, see rich text.” (18) Row 横行. Consider modifying to 字符区 as row-cell structure is similar to 区位/ku-ten. (19) Script 手稿程式. Consider modifying to 文种 according to “基本多文种平面”. And the Glossary of Unicode Terms only contains the meaning item of 文种 without 脚本 and 书体. (20) Spacing Mark 间距标记. Consider modifying to 含宽标记. Reference [1] 计算机科学技术名词 (第三版).
(None at this time.)