The sections below contain links to permanent feedback documents for the open Public Review Issues as well as other public feedback as of January 11, 2019, since the previous cumulative document was issued prior to UTC #158 (January 2019).
The links below go directly to open PRIs and to feedback documents for them, as of January 8, 2019.
(There were no open Public Review Issues during this reporting period.)
The links below go to locations in this document for feedback.
Feedback to UTC / Encoding Proposals
Feedback on UTRs / UAXes
Error Reports
Other Reports
Note: The section of Feedback on Encoding Proposals this time includes:
L2/17-112R
L2/18-036
L2/18-314
L2/19-051
L2/19-069
L2/19-082
Date/Time: Tue Jan 22 10:28:20 CST 2019
Name: Marcel Schneider
Report Type: Feedback on an Encoding Proposal
Opt Subject: Comments on
L2/18-314 Mongolian Ad Hoc meeting summary
The Mongolian Ad Hoc meeting summary [1] contains a mention about reaching out to Microsoft in order to get various fixes in Word and more generally in Office. Given the fixes for Mongolian include improved handling of NNBSP, I suggest that in the wake, an option be added to the French linguistical pack, enabling the user to choose from both NBSP (legacy) and NNBSP (correct) on a per-character basis, with a default of NNBSP for all eligible punctuation marks (question and exclamation mark, (semi-)colon, (single/double) angle quotation marks. When NNBSP is choosen, the user should be able to tune colon back to NBSP so as to match the Imprimerie nationale style manual (INSM). The same should be possible for the double angle quotes, although the INSM does not typeset them with NBSP but with NNBSP. The same space should be used as group separator. This issue is also related to German and other locales using space as group separator (not period as erroneously stated in CLDR). [1] https://www.unicode.org/L2/L2018/18314-mongolian-ad-hoc.pdf
Date/Time: Tue Jan 15 10:44:49 CST 2019
Name: David Corbett
Report Type: Feedback on an Encoding Proposal
Opt Subject: YEZIDI LETTER UUM
L2/19-051 proposes YEZIDI LETTER UUM, with a representative glyph like a kerned pair of YEZIDI LETTER UMs. Does “û” (uum) ever contrast with “uu” (um + um)? Figures 4 and 5 both include the word “Xatûna”, but in figure 4 the two ums are not kerned any closer together than any other two letters, implying that the kerned form as in figure 4 is an optional feature, which, like the lam ligatures, should not be encoded atomically. See also https://www.unicode.org/faq/ligature_digraph.html#Dig2 .
Date/Time: Tue Apr 2 05:00:41 CDT 2019
Name: Andrew West
Report Type: Feedback on an Encoding Proposal
Opt Subject: Feedback on Proposal to encode the Old Turkic ligature ORKHON CI
In L2/19-069 "Proposal to encode the Old Turkic ligature ORKHON CI" Anshuman Pandey proposes to encode a new character to represent a ligature form of two Old Turkic letters. My understanding is that ligatures of this kind this should be represented at the encoding level as ZWJ sequences (10C32 200D 10C03 in this case), and not as a single encoded character. Existing ligature characters in the Unicode Standard, such as those in the Alphabetic Presentation Forms block, were provided for compatibility with legacy standards, and do not provide a precedent for encoding new ligature characters. Accepting Old Turkic ligature ORKHON CI for encoding would open the doors to encoding hundreds of ligatures used in other scripts such as Latin and Runic, and so I strongly oppose the encoding of Old Turkic ligature ORKHON CI.
Date/Time: Tue Apr 2 05:45:45 CDT 2019
Name: Andrew West
Report Type: Feedback on an Encoding Proposal
Opt Subject: Feedback on QID Emoji Proposal
In L2/19-082 "QID Emoji Proposal" Mark Davis proposes a mechanism that allows for any object, person, place, or concept that has a Wikidata ID to be representable as an emoji (there are currently over 55 million Wikidata items). Although this may seem at first sight to be a clever way of allowing vendors to support a wider range of emoji than the Unicode Standard currently allows for, it opens up a whole new can of worms, and if accepted would only cause endless problems and complaints in the future. This mechanism could be seen as an attempt to deflect criticism away from the Unicode Consortium onto Wikidata and vendors, so that when the public or the press complain to the UTC that such or such an emoji is lacking, the UTC can simply shrug their shoulders and tell them to ask Wikidata to add an ID and vendors to support an emoji for that ID. Firstly, this in unfair on Wikidata, which never asked to become a repository for potential emoji, and secondly will not save the Unicode Consortium from criticism if Wikidata does not have an ID for Banana and Custard Pizza (for example) or if vendors do not support a particular ID, or if vendors implement the emoji for an ID inconsistently. The Unicode Consortium will still be seen as the people to blame, even though there is nothing the UTC can do to solve perceived issues with Wikidata and vendor implementations of Wikidata IDs. Emoji for famous people, deities, and brands are explicitly excluded under the current Emoji guidelines, but as Wikidata covers everything notable in the known universe, famous people, deities and brands will be representable as emoji, and given the huge popular demand for emoji for popstars such as Prince and David Bowie, they will certainly happen very quickly. No doubt companies will also pay large sums of money to get vendors to support emoji for their brands, and political parties will pay vendors to support emoji for their candidates. Will people and companies then be able to adopt an emoji for a particular Wikidata ID, and get advertising exposure on the Unicode website for Heinz Baked Beans or Coca-Cola (for example)? Or could people even adopt any Wikidata ID emoji, even those that have not been (and probably never will be) implemented by any vendor in order to get exposure on the Unicode website for absolutely anything? Does the Unicode Consortium really want to get embroiled in the commercialization and politicization of emoji? Wikidata may seem like a great repository for potential emoji, but it also provides scope for confusion and incompatible implementations by different vendors because a single thing or concept often maps to multiple different Wikidata IDs, or there may be multiple Wikidata IDs that are the closest match to the desired emoji. Therefore different vendors could easily end up implementing equivalent emoji glyphs as different Wikidata IDs, causing interoperability issues. I urge the UTC to firmly reject this proposal!
Date/Time: Thu Apr 4 02:31:31 CDT 2019
Name: William Overington
Report Type: Feedback on an Encoding Proposal
Opt Subject: A suggestion regarding font support in relation to QID emoji
A suggestion regarding font support in relation to QID emoji William Overington Wednesday 3 April 2019 In the document L2/19-082 QID Emoji proposal, on page 3, in the section headed Interchange, there is mention of the need, if a display of the character is to be produced at the receiving end, for a font with a glyph for the character being available at the receiving end. I remember that in February 2003 I started a thread in the Unicode public mailing list (please note that the email address listed by me in that thread is no longer in use) with the title ‘Hot Beverage font.’. The post is about a font that I had produced and published. The font is still available. The font includes just one glyph, for the then newly encoded U+2615 HOT BEVERAGE character, though accessible both with that code point and also with a lowercase h in case that might be helpful in some circumstances. I am wondering if at the same time as the encoding of the new character that is suggested in the QID Emoji proposal document that the Unicode Technical Committee could please consider specifying a font name format and a file name format for a single glyph font for a QID emoji. For example, for a font with just a single glyph for the White-crested tiger heron emoji that is mentioned in the QID Emoji document, maybe the glyph could be in a font that has a font name of fontQ218543 in a file named fontQ218543.otf so that the internet, or some part thereof, could be searched for a single glyph font for the particular emoji. If these single glyph fonts were all made available using the SIL Open Font License font licensing facility, then maybe that could be beneficial for assisting interoperability of QID emoji. Reference: Overington, W. J. G., Hot Beverage font. https://www.unicode.org/mail-arch/unicode-ml/y2003-m02/0338.html
Date/Time: Thu Apr 4 02:40:44 CDT 2019
Name: William Overington
Report Type: Feedback on an Encoding Proposal
Opt Subject: QID Emoji and text-to-speech
QID emoji and text-to-speech William Overington Thursday 4 April 2019 I have noticed that there exists potential for the information in the QID page related to the White-crested tiger heron emoji that is mentioned in the L2/19-082 QID Emoji proposal document to be used for text-to-speech in various languages.
Date/Time: Wed Apr 10 15:25:00 CDT 2019
Name: Lee Collins
Report Type: Error Report
Opt Subject: Wrong radical for U+2B5CC
U+2B5CC, a V-source character, uses a simplified form of Radical 183, 飞. The RS should be 183'.8 not 183.8
Date/Time: Wed Apr 10 16:11:23 CDT 2019
Name: David Corbett
Report Type: Error Report
Opt Subject: Incomplete Egyptian Hieroglyph Format Controls section
The “Egyptian Hieroglyph Format Controls” section does not contain enough detail to implement a system that uses Egyptian hieroglyph format controls. It does not explain operator precedence, how to order multiple insertions on the same base glyph, under what circumstances insertions require explicit segment grouping controls, or how to deal with incomplete quadrats. It mentions but does not define “level”. This is a good way to get incompatible implementations. L2/17-112R is just a proposal, but it has a better specification, with many examples and diagrams. That is the level of detail that should be in the standard for something as nonobvious as this.
Date/Time: Wed Apr 10 17:21:46 CDT 2019
Name: David Corbett
Report Type: Error Report
Opt Subject: RTL glyphs of Egyptian hieroglyph format controls
Egyptian hieroglyphs may be written RTL. U+13432..13435 and U+13437..13438 are not default ignorable. It would be confusing for these characters to have the same glyphs in both LTR and RTL text. It would be helpful for the standard to recommend mirroring them, as it says in the “Directionality” section for hieroglyphs, for fonts that use glyphs similar to those in the code charts, or partially mirroring them for glyphs like the ones at the bottom of page 2 and on page 3 of L2/18-036.
Date/Time: Thu Feb 28 19:10:54 CST 2019
Name: Andrew West
Report Type: Error Report
Opt Subject: UTS #51 Unicode Emoji 12.0 Section 2.8
UTS #51 Unicode Emoji 12.0 Section 2.8 "Emoji Glyph Facing Direction" has the following problems: 1. It does not explicitly tell the reader the actual code point sequences to use for the ZWJ mechanism to indicate direction. In particular, the code points of the left and right arrows should be specified as there are hundreds of left and right arrows in the Unicode Standard. 2. If you copy the pictures in the table, and paste elsewhere in order to find out what the underlying code points are, you get the following because the alt attributes of all the img tags have the wrong details: Internal Representation Intended Display Fallback Appearance 👩❤️❤️ 👩 👩❤️ 👩❤️❤️ 👩 👩❤️
Date/Time: Thu Mar 21 10:22:15 CDT 2019
Name: Klaus Hartke
Report Type: Error Report
Opt Subject: Ambiguity in identifier profile example (UAX 31)
(Ed note: The same problem still exists in https://www.unicode.org/reports/tr31/tr31-31.html)
Section 2 of https://www.unicode.org/reports/tr31/tr31-29.html gives the following example for a profile: Start := XID_Start, plus some characters from Table 3 Continue := Start + XID_Continue, plus some characters from Table 3b Medial := some characters from Table 3a One of the characters from Table 3a is U+00B7 MIDDLE DOT. However, it seems that U+00B7 is already a XID_Continue character. This creates some ambiguity when parsing. Should the example be excluding Medial characters from Continue characters?
Date/Time: Tue Apr 2 10:48:22 CDT 2019
Name: David Corbett
Report Type: Error Report
Opt Subject: Undefined variable in UAX #31
Condition A2’s regex uses the variable $L2, but $L2 is not defined. It should simply be $L.
Date/Time: Tue Feb 12 15:54:25 CST 2019
Name: David Corbett
Report Type: Error Report
Opt Subject: Underspecified U+23B7 RADICAL SYMBOL BOTTOM
UTR #25 does not explain how to use U+23B7 RADICAL SYMBOL BOTTOM. Section 2.13 mentions it but Table 2.6 does not explain it. L2/00-159 has some suggestions; the only one that is self-consistent is to use the box drawing characters U+2502, U+250C, and U+2500 for the vertical line, corner, and horizontal line.
Date/Time: Tue Feb 12 15:57:28 CST 2019
Name: David Corbett
Report Type: Error Report
Opt Subject: Typo in MathClassEx-15.txt
https://unicode.org/Public/math/latest/MathClassEx-15.txt contains this line:
FFE9..FFEC;X;￩..￬;;; ("wide" compatibility variants of arrows);HALFWIDTH LEFTWARDS ARROW..HALFWIDTH DOWNWARDS ARROW
Those arrows are not wide variants. They are narrow.
Date/Time: Tue Feb 12 15:59:19 CST 2019
Name: David Corbett
Report Type: Error Report
Opt Subject: Wrong names list note for U+20E6 COMBINING DOUBLE VERTICAL STROKE OVERLAY
The names list note for U+20E6 COMBINING DOUBLE VERTICAL STROKE OVERLAY is “z notation finite function diacritic”. However, according to ISO/IEC 13568, finite functions use U+21FB RIGHTWARDS ARROW WITH DOUBLE VERTICAL STROKE and U+2915 RIGHTWARDS ARROW WITH TAIL WITH DOUBLE VERTICAL STROKE. The vertical strokes are already part of those characters, so no diacritic is necessary. Therefore U+20E6 is not used in Z notation and the note should be removed.
Date/Time: Wed Feb 13 13:48:22 CST 2019
Name: David Corbett
Report Type: Error Report
Opt Subject: Characters with question marks in BidiMirroring.txt
U+2A7B LESS-THAN WITH QUESTION MARK ABOVE and U+2A7C GREATER-THAN WITH QUESTION MARK ABOVE mirror each other with the comment “[BEST FIT]” in BidiMirroring.txt. U+225F QUESTIONED EQUAL TO is listed in the comment at the bottom. That implies that when those three characters appear in RTL text, their question marks should be mirrored. This is unlike U+003F QUESTION MARK, which is not mirrored to U+2E2E REVERSED QUESTION MARK. L2/18-049R says U+2A7B and U+2A7C are a best fit pair but doesn’t discuss why it should not be a perfect pair. Would these question marks be mirrored in RTL math, even in Hebrew, which uses U+003F? If not, the “[BEST FIT]” comment should be removed from the first two, and U+225F should be removed from the comment at the bottom.
Date/Time: Thu Feb 14 14:31:50 CST 2019
Name: David Corbett
Report Type: Error Report
Opt Subject: Inconsistent Bidi_Mirrored for glyph parts
The only glyph parts with Bidi_Mirrored=Yes are U+2320 TOP HALF INTEGRAL and U+2321 BOTTOM HALF INTEGRAL. Why should the integral parts be mirrored but not the bracket and summation sign parts? If the integral parts stay mirrored, then U+23AE INTEGRAL EXTENSION should have Bidi_Mirrored=Yes to match them, because an unmirrored U+23AE is not guaranteed to align with a mirrored U+2320 and U+2321.
Date/Time: Thu Feb 21 12:40:47 CST 2019
Name: Robert Ross
Report Type: Error Report
Opt Subject: Strange choices in EastAsianWidth.txt
It seems wrong that 23F1 and 23F2 are narrow in "EastAsianWidth.txt" when 23F0 is wide. In "U2300.pdf" (the Miscellaneous Technical code chart) and in every relevant font I could find (Symbola, NotoSansSymbols2, and Unifont), all of these glyphs are wide.
Date/Time: Sun Feb 24 08:06:42 CST 2019
Name: David Corbett
Report Type: Error Report
Opt Subject: Typo in UTR #25
In UTR #25, “SOFTWARE FUNCTION” should be “SOFTWARE-FUNCTION”.
Date/Time: Thu Feb 28 07:39:54 CST 2019
Name: Axel Svensson
Report Type: Error Report
Opt Subject: Error in references to similar characters
See https://www.unicode.org/charts/PDF/U2500.pdf The characters 2571 and 2572 have each three references to similar characters: 2571 -> 005C -> 2216 -> 29F5 2572 -> 002F -> 2044 -> 2215 These are actually not similar, and the references should probably be changed to: 2571 -> 002F -> 2044 -> 2215 2572 -> 005C -> 2216 -> 29F5
Date/Time: Thu Feb 28 00:19:42 CST 2019
Name: Sascha Brawer
Report Type: Error Report
Opt Subject: Integrate Microsoft overrides for IndicSyllabicCategory.txt and IndicPositionalCategory.txt
In context of the OpenType Universal Shaping Engine, Microsoft has published a set of overrides to Unicode’s “Indic Syllabic Category” and ”Indic Positional Category” data files. I would like to propose merging Microsoft’s overrides into Unicode’s data files. This would reduce overall complexity, and (at least to my knowledge) text rendering engines are the only users of these Unicode properties anyway. Please note that I’ve no relation to Microsoft. I’m just a user who would like to consume Unicode’s data without applying additional patches/overrides. — Sascha Brawer, sascha at brawer.ch (a) Overrides to ucd/IndicSyllabicCategory.txt: https://docs.microsoft.com/en-us/typography/script-development/use#overrides-to-indicsyllabiccategory # Indic_Syllabic_Category=Bindu AA29 ; Bindu # Mn CHAM VOWEL SIGN AA # ================================================ # Indic_Syllabic_Category=Nukta 0F71 ; Nukta # Mn TIBETAN VOWEL SIGN AA # ================================================ # Indic_Syllabic_Category=Tone_Mark A982 ; Tone_Mark # Mn JAVANESE SIGN LAYAR # ================================================ # Indic_Syllabic_Category=Consonant_Dead 0F7F ; Consonant_Dead # Mc TIBETAN SIGN RNAM BCAD # ================================================ # Indic_Syllabic_Category=Gemination_Mark 11134 ; Gemination_Mark # Mc CHAKMA MAAYYAA (b) Overrides to ucd/IndicPositionalCategory.txt https://docs.microsoft.com/en-us/typography/script-development/use#overrides-to-indicpositionalcategory # Indic_Matra_Category=Top 0F74 ; Top # Mn TIBETAN VOWEL SIGN U AA35 ; Top # Mn CHAM CONSONANT SIGN 1A18 ; Top # Mn BUGINESE VOWEL SIGN U # ================================================ # Indic_Matra_Category=Bottom 0F72 ; Bottom # Mn TIBETAN VOWEL SIGN I 0F7A..0F7D ; Bottom # Mn [4] TIBETAN VOWEL SIGN E..TIBETAN VOWEL SIGN OO 0F80 ; Bottom # Mn TIBETAN VOWEL SIGN REVERSED I 11127..11129; Bottom # Mn [3] CHAKMA VOWEL SIGN A..CHAKMA VOWEL SIGN II 1112D ; Bottom # Mn CHAKMA VOWEL SIGN AI 11130 ; Bottom # Mn CHAKMA VOWEL SIGN OI
Date/Time: Wed Mar 6 17:31:21 CST 2019
Name: Charlotte Buff
Report Type: Problems / Feedback about website
Opt Subject: Wrong character total for Unicode 12
(Ed Note: this was already forwarded to the editors.)
On the overview page for Unicode 12.0 (https://www.unicode.org/versions/Unicode12.0.0/) the total number of characters in the standard is given as 137,929. However, the true number is one less than that (137,928) if C0 and C1 controls are not counted.
Date/Time: Mon Mar 11 13:53:51 CDT 2019
Name: David McCreedy
Report Type: Error Report
Opt Subject: Unihan USourceData.txt errors
Hello. I’ve found a few issues in the UTCDoc data in the Unihan database file USourceData.txt: L2-12/333 uses the wrong format and should be L2/12-333 (several occurrences) L2/16‐066 and L2/16‐269 use U+2010 HYPHEN instead of the expected U+005D HYPHEN-MINUS several occurrences). They should be L2/16-066 and L2/16-269. These issues create difficulties in searching or parsing the file. Thank you. -David
Date/Time: Sat Mar 30 00:55:23 CDT 2019
Name: Leo
Report Type: Other Question, Problem, or Feedback
Opt Subject: Two CJK radicals that seems to be redundant
(Ed Note: this report is already being addressed by the editors.)
Hi, Just to note first that I might have miscategorized the Type of Message this should belong to so please forward to the relevant department if necessary as I am not very familiar with how works are carried out here. The question I have is that I was looking through the CJK Radicals for the Unicode 12.0 version and it seems that there are two characters that look seemingly exactly the same, namely U+2E90 in the Radicals Supplement and U+2F2A in the Kangxi Radicals; I don't see why there should be the case that there should be two copy of what seemingly is the same one character--that is, they don't seem like variants of each other however you look them and since both blocks seems to be introduced in the same version (Unicode 3.0 I believe) there shouldn't be any compatibility reason. Between the two blocks there doesn't seem to be any other characters that look this strikingly the same so perhaps this is an oversight. Please have a look into this. Thanks. Here is the two characters for quick reference: ⺐⼪
Date/Time: Tue Apr 2 10:13:24 CDT 2019
Name: David Corbett
Report Type: Error Report
Opt Subject: Problems with Table 7-1
Table 7-1 “Preferred Rendering of Cedilla versus Comma Below” says that the comma below glyph of U+0327 COMBINING CEDILLA should be used with d, g, k, l, n, r, and t. The table should not recommend a comma glyph below t, because they is needlessly ambiguous with U+021B LATIN SMALL LETTER T WITH COMMA BELOW, and might encourage people to use the wrong diacritic in Romanian because it looks right in a particular font. The section “Latvian Cedilla” contradicts the table, saying that with g it should look like a rotated comma above. That section says “The uppercase form of the letter [G] is always shown with a cedilla” but the code chart shows it with a comma. The table should explain that U+0327 should look like a comma under certain capital letters, not just small letters.
Date/Time: Tue Apr 2 10:22:49 CDT 2019
Name: David Corbett
Report Type: Error Report
Opt Subject: Script_Extensions of U+0485 and U+0486
U+0485 COMBINING CYRILLIC DASIA PNEUMATA and U+0486 COMBINING CYRILLIC PSILI
PNEUMATA have sc=Zinh and scx={Cyrl Latn} because of L2/08-049. The
precedent of U+A7BA LATIN CAPITAL LETTER GLOTTAL A etc. makes that obsolete.
Date/Time: Tue Apr 2 10:36:59 CDT 2019
Name: David Corbett
Report Type: Error Report
Opt Subject: Tamil characters in Grantha
The Grantha section of The Unicode Standard says “Grantha makes use of the Tamil digits U+0BE6 through U+0BEF.” It should mention the other Tamil numbers it uses too (see Script_Extensions).
Date/Time: Tue Apr 2 10:41:35 CDT 2019
Name: David Corbett
Report Type: Error Report
Opt Subject: Confusion regarding the glyph of U+0F0E TIBETAN MARK NYIS SHAD
Regarding Tibetan punctuation, chapter 13 says “Because some writers use the double shay with a different spacing than would be obtained by coding two adjacent occurrences of U+0F0D, the double shay has been coded at U+0F0E with the intent that it would have a larger spacing between component shays than if two shays were simply written together. However, most writers do not use an unusual spacing between the double shay, so the application should allow the user to write two U+0F0D codes one after the other. Additionally, font designers will have to decide whether to implement these shays with a larger than normal gap.” I’ve downloaded a bunch of Tibetan fonts and most of them display U+0F0E as slightly narrower than two U+0F0Ds. Many make them the same width. A few of the Qomolangma fonts make U+0F0E slightly wider. The code chart glyph for U+0F0E consists of two shays so close together there is barely any space between them. If the standard is correct, the code chart glyph is misleading, if not wrong, and should have more space between the shays. If the majority of my test’s fonts are correct, chapter 13 should not imply their spacing is wrong.
Date/Time: Tue Apr 2 10:57:11 CDT 2019
Name: David Corbett
Report Type: Error Report
Opt Subject: Obsolete ranges in Table 4-8
The ranges in Table 4-8 of The Unicode Standard have not been updated for version 12.0.
Date/Time: Tue Apr 2 11:09:51 CDT 2019
Name: David Corbett
Report Type: Error Report
Opt Subject: Typo in Chakma section
The Chakma section of The Unicode Standard calls the candrabindu “cānaphupudā”. It should be “cānaphudā”. See https://hilledu.com/discussion-about-my-hakma-font/ where it is spelled “চানফুদ”.
Date/Time: Tue Apr 2 12:10:23 CDT 2019
Name: Sridatta A
Report Type: Error Report
Opt Subject: IndicPositionalCategory for Mahajani and Kayah Li
In https://www.unicode.org/Public/12.0.0/ucd/IndicPositionalCategory.txt It is mentioned 'Indic scripts without positional characters are # Kayah Li, Mahajani, Multani, Phags-pa, and Tai Le.' However 11173 MAHAJANI SIGN NUKTA has Indic_Positional_Category property value = Bottom. Similarly A92B..A92D KAYAH LI TONE PLOPHU..KAYAH LI TONE CALYA PLOPHU have Indic_Positional_Category property value = Bottom. these two scripts may be included in the List of Indic scripts having positional characters ' # The scripts assessed as containing dependent vowels or similar characters # in the structural sense used for the Indic_Positional_Category are the # following:' listed in that file and be removed from list of Indic scripts without positional characters.
Date/Time: Thu Apr 11 08:54:29 CDT 2019
Name: David Corbett
Report Type: Error Report
Opt Subject: More Identifier_Type=Obsolete characters
The following should have Identifier_Type=Obsolete. • U+0500..U+050F, like the other Komi letters U+052A..U+052D • U+09FC, like the other Vedic anusvaras • U+0D3B..U+0D3C, old Malayalam viramas • U+1C80..U+1C88, Church Slavonic glyph variants • U+312E BOPOMOFO LETTER O WITH DOT ABOVE, replaced by U+311C BOPOMOFO LETTER E • U+A660..U+A661 CYRILLIC CAPITAL/SMALL LETTER REVERSED TSE • U+A674..U+A67B + U+A69E..U+A69F, like the other combining Cyrillic letters • U+A790..U+A791 LATIN CAPITAL/SMALL LETTER N WITH DESCENDER • U+A7A0..U+A7A9, obsolete Latvian letters • U+06A1 ARABIC LETTER DOTLESS FEH, like U+066E ARABIC LETTER DOTLESS BEH
Date/Time: Sat Apr 27 21:09:28 CDT 2019
Name: David Corbett
Report Type: Error Report
Opt Subject: Wrong example in Table 11-2
The third row of Table 11-2 “Complex Hieroglyphs and Nonequivalent Sequences” says to use 13196 instead of <13193, 13430, 133CF, 13430, 131FF>. However, according to the conventions of L2/17-112R, that sequence does not actually encode the quadrat in question. The sequence to not use should be <13193, 13433, 13437, 133CF, 13430, 131FF, 13438>.
Date/Time: Sat Apr 27 21:27:08 CDT 2019
Name: David Corbett
Report Type: Error Report
Opt Subject: Obsolete caveat in UAX #50
UAX #50 says that Egyptian hieroglyphs require markup like the Manuel de Codage. As of Unicode 12.0 this is no longer true.
Subject: Khowar language special characters Date: Mon, 4 Mar 2019 08:59:39 +0000 (UTC) From: Rehmat Aziz Chitrali
Dear sirThe special characters of Khowar language are not joining each other in windows 10, here are the examples ݱ- ریݱ، ݯ -ݯھترار، ݮ- ݮنݮیر، ݰ- ݰوݰپ، څ - څھوعو، ځ - ځعفرانplease copy these text into Ms Word and check and help us.With Profound Regards
Rehmat Aziz Chitrali