Comments on Public Review Issues
(January 11 - April 28, 2019)

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 


Feedback to UTC / Encoding Proposals

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

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

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

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.
Overington, W. J. G., Hot Beverage font. 

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

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.

Feedback on UTRs / UAXes

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.

Error Reports

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

“z notation finite function diacritic”. However, according to ISO/IEC 13568,
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

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


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:

 -> 005C
 -> 2216
 -> 29F5

 -> 002F
 -> 2044
 -> 2215

These are actually not similar, and the references should probably be changed to:

 -> 002F
 -> 2044
 -> 2215

 -> 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

— Sascha Brawer, sascha at brawer.ch

(a) Overrides to ucd/IndicSyllabicCategory.txt:

# 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

# 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
  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

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.


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.)


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

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+A674..U+A67B + U+A69E..U+A69F, like the other combining Cyrillic letters
• U+A7A0..U+A7A9, obsolete Latvian letters

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.

Other Reports

Subject:   Khowar language special characters
Date:   Mon, 4 Mar 2019 08:59:39 +0000 (UTC)
From:   Rehmat Aziz Chitrali

Dear sir

The 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