Accumulated Feedback on PRI #286

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: Wed Nov 12 20:12:21 CST 2014
Name: Thomas Bishop
Report Type: Public Review Issue
Opt Subject: UTR #51 and L2/14-213

I oppose the proposed white-first/black-last ordering of emoji skin-tone
modifiers proposed in the first draft of tr51, on the grounds that it is
(unintentionally) racist.

I also oppose the proposal for encoding of five skin-tone modifier code points
in its current form

on the grounds that the white-before-black ordering of code points would
contribute to (unintentionally) racist software of the type described in the
first draft of tr51. Also, according to the proposal, contact has not been
made to members of the user community. It would be negligent to approve such a
sensitive and controversial proposal without seeking extensive advice from
experts in ethnic studies, equity studies, institutional bias, dermatology,

Please see extensive discussion on the UnicoRe mailing list with the subject,
"New Unicode Emoji draft (tr51) and skin tone". Thank you!

Date/Time: Thu Nov 13 03:07:18 CST 2014
Name: Kat Momoi
Report Type: Public Review Issue
Opt Subject: TR 51 -- the term "emoji"

Am I incorrect in assuming that the term "emoji" became common within the
Unicode community during the process to add ARIB and Japanese carrier symbols
to the Unicode Standard?

If I am correct, then, should we not mention this as a history of the term in
the Unicode Standard? And that we are now retroactively applying this term to
symbols that had been in the Unicode standard prior to Unicode 5.2 when the
ARIB characters were added.

- Kat

Date/Time: Wed Nov 5 19:54:06 CST 2014
Report Type: Public Review Issue
Opt Subject: On Unicode Emoji - Proposed Draft Unicode Technical Report #51

Regarding the  Proposed Draft Unicode Technical Report #51 - Unicode Emoji
found at - retrieved on

On the numeral 2.2 "Diversity" - an encoding for skin color is presented. As
exposed the skin color can be carried on any Unicode text stream with no
additional format (that is, without html or similar).

On your consideration...

As I understand it, the proposal is not meant for software that does not have
special treatment of Emoji. Although there may be applications that may
benefit from similar standard for other uses. In particular SMS seems
problematic because the only mechanism to convey this information is the body
of text of the message and we want to maintain compatibility as much as

There are two ways to look at this:
1 - It is too little of an improvement
2 - It is better to not have it

For abstract, I see the proposal as just a compromise.

1 - It is too little of an improvement

I find the following issue with the proposal: it will generate demand while
lacking extensibility for some aspects such as hair color that may be
misrepresented (blonds / ginger, etc...)

There is an antecedent of changing color over a simple text stream, and it is
on text terminals. While there is not an universal standard for the encoding
of this information - that I know of -, the common implementations are based
on escape sequences - not far fetch from modifier characters.

For a general solution, I may suggest to use an approach that may allow the
representation of any color on any character, and to apply multiple
modification on the same character. As an standard this could be implemented
on text terminal ("universal"^2 color encoding independent of the terminal),
chat and instant message applications (diversity and personalization3), web
browsers4, text editor, etc. Yet that raises the concern of whatever it is
competing with other ways of modding text.

2: software translation may be required. 

3: beyond skin or hair color, consider code points U+1F499 (blue heart),
U+1F49A (green heart), U+1F49B (yellow heart) and U+1F49C (purple heart) will
be accompanied with modded ^U+2764 (heavy black heart) for other colors, among
other things, for example a yellow U+1F339 (rose) or even a blue U+1F34B
(lemon). 4: There is potential for the use of these for building web pages.
Custom fonts for representing special symbols has been available for a while,
although using official code points is better for compatibility in general
and screen readers in particular.

As far as chat and instant messages goes, it may be an option for those apps
to move to gzipped html (or similar) and have this solved at css level.

Yet, the idea - that I mentioned above - of encoding any color has problems:
1) it lacks semantics, 2) stumble how to encode the colors.

A shorthand may be to use a palette with semantic entries, while keeping a
more extensive color encoding as optional (if at all available). On the
problem of how to read the color (for screen readers) when color beyond the
semantic palette are used, it would be necessary to resource to nearest html
color or nearest pantone color.


As for building a face for emoji, it seems it can be divided into components:
- skin color
- gender
- clothes
- expression
- hair color (optional)
- eye color (optional)
- age (optional)

Some characters would have some default values for these, and by using
modifier characters these values can be altered. So it will be possible to
create - for example - a happy female of high fitzpatrick type that is wearing
a turban. My similar means you can put bunny ears on a man (modding the
gender), or even on a moon with a face (modding the clothes).

2 - It is better to not have it

At the end it is just another way to encode metadata on text. You are setting
some properties of the character by using modifier characters. How powerful or
extensible this mechanism will be is up for discussion.

For instance you may consider representing multiple races of dogs. If
including that into Unicode is worth it, is another topic. Consider for
example that some animals seems to have the privilege to get a code point. It
does not seems good venture to try to encode all animal species into Unicode.
Yet, you may consider the scenario where push may come to include some species
as a campaign to raise awareness on endangered species. The approach of
collecting what implementations does is safer on this regard... then, what are
implementations doing about skin tone? and why does it seems that this has to
come from Unicode to be improved?

On this line of thought, this improvements will never be enough.


Going back to the roots, Emoji are meant to transmit emotion via expression -
it is good to have a way to communicate this that is agnostic of race. While
the argument that yellow seems closer to Caucasian or Asiatic skin tones can
be made, yellow is actually neither, and that is good.

Maybe we should make all Emoji gray, 50% between black and white. If we
consider all human equal, maybe Emoji should represent that in the most
neutral way. On Internet you can be chatting of people of other races, and
there is no need to know. You can deaf and still be equal to everybody.

On the other hand expressing diversity is a worthy option. The extreme of this
is to mod the Emoji as an avatar. It is workable to have a set of customizable
avatars that will be used to represent your Emoji on a chat or instant message
session (so you can have your avatar with blue skin if you like - maybe you
have blue skin) - and that would be beyond the scope of Unicode.

The user will probably set the race / skin tone / custom avatar or whatever
technology is used at the end, and will do it only once via configuration1. So
this information can be sent to the other end only once, and this way there
will be no need to encode this in the text of the message. Except for text
messages (SMS) - sending extra characters to convey this information means
that sending this information is more expensive (because SMS is limited by the
number of characters) - this means that expressing diversity in Emoji is a
luxury (albeit a cheap one) - It may be better to replace SMS with something
else that will allow for better and perhaps cheaper transmission of metadata
than to accommodate to it.

1: meaning that the servers may know your race / skin tone - and try to use
this information to direct advertising to you. Telling the servers your race /
skin tone raises privacy concerns.


I have presented two sides of this. On one side extending the standard beyond
the proposal will allow new uses cases, on the other this does not seem to be
a task to be solved by extending Unicode to allow the encoding of metadata on
SMS, but by replacing SMS.

All on your consideration. Hope you make the possible of this proposal.

Date/Time: Fri Nov 14 16:35:30 CST 2014
Name: Andrew West
Report Type: Public Review Issue
Opt Subject: New Emoji Candidates for Unicode 8.0

The Unicode 8.0 candidate character BADMINTON RACQUET AND BIRDIE should be
named BADMINTON RACQUET AND SHUTTLECOCK as "shuttlecock" is the correct
technical term, and "birdie" is an informal term not widely used outside the

Date/Time: Fri Nov 14 17:02:14 CST 2014
Name: Doug Ewell
Report Type: Feedback on an Encoding Proposal


Date/Time: Wed Nov 19 15:57:57 CST 2014
Name: Tim Larson
Report Type: Public Review Issue
Opt Subject: race and Unicode - TR51

Comment by on 2014/11/05 is correct. The consortium
seems to be tripping over itself in a frenzy of political correctness. How a
smiley face is displayed is irrelevant, that's a font issue. You've correctly
encoded an emotional expression (smile, cold sweat, tired, etc) and that is
all that is intended. Persons taking umbrage to one particular visual
representation of that character and expecting Unicode to address it miss the
point of what Unicode is for/about. The writer correctly points out that this
whole discussion is about metadata, and if you start down that path, where
does it end? Hair color, hair amount/presence, eye color?

Perfect case in point, see comment by Thomas Bishop on 2014/11/12. Even if you
do add support for one spectrum of possibilities, those who take political
offense to the issue will still find some fault. There's no way to create a
list without one item being first and thus having the perception of being

This whole non-issue should be avoided by Unicode. The path leads to
absurdity. Don't start down it.

Date/Time: Thu Nov 20 10:31:41 CST 2014
Name: Doug Ewell
Report Type: Public Review Issue
Opt Subject: race and Unicode - TR51

For the record, I agree with Tim Larson and others that the skin-tone modifier 
characters are unnecessarily politically correct, possibly racist, and out of 
scope for plain-text encoding. I realize this will not impede the proposal.

Date/Time: Thu Nov 27 03:02:32 CST 2014
Name: Chris Ward
Report Type: Feedback on an Encoding Proposal
Opt Subject: Proposed new emoji characters

Religious and superstitious symbols (zodiac) should NOT be added. 
The world needs to move forwards.

The following should be considered:

Everyday items:
• Shopping basket or trolley
• Walkie-talkie

• Motorbike
• Quad bike
• Forklight truck
• Bulldozer and/or digger
• Construction crane
• Hovercraft
• Fighter jet
• Warship
• Submarine
• Tank
• Satellite

• Astronaut

• Golf ball (the golf flag is too vague)

All missing flags

• The gas/petrol pump [9981] should not have 'G' on it, making it language specific.

• USB symbol or plug
• Radiation symbol (on a yellow background)

Date/Time: Fri Nov 28 15:19:39 CST 2014
Name: Takashi Kazama
Report Type: Public Review Issue
Opt Subject: UTR #51, Unicode Emoji

The following should be considered.

Tool symbols: gavel

I agree to your guideline ,UTR #51  Annex C: Selection Factors Expected 
Usage Level : multiple usages.
The source of U+1F528 HAMMER is Japanese carrier emoji.
From 1995 to 1998,famous TV show "Hammer Price" was broadcast in Japan.
So auction gravel is called hammer by most Japanese.
The carrier's font of hammer emoji is a double face sledge hammer.
The shape of doble face sledge hammer has a resemblance to a gavel.
I guess ,hammer emoji is used as not only a DIY tool but also auction 
gavel and judge gavel.

The Unicode reference glyph of U+1F528 HAMMER looks like a claw hammer.
The implementation of U+1F528 HAMMER was changed to a claw hammer, that 
became a topic in Japan.

I think the shape of a claw hammer is unsuitable for messages about auction or judgement.

Date/Time: Wed Jan 14 22:06:58 CST 2015
Name: OGATA Katsuhiro
Report Type: Public Review Issue
Opt Subject: Comment to PRI 286

■2.2 Diversity

Several different Following terms are used to mean the idea of “Emoji Modifiers”. 

•Emoji Skin Tone Modifiers
•skin tone modifie

They should be replaced by “EMOJI MODIFIERS” that used in the latest PDAM ballot 
text for Amd.2 (

■2.2.1 Implementations

Following characters should be removed from the list in “Characters Subject to 
Emoji Modifiers: Optional Set”. Because they do not include the skins to be changed 
by the modifiers.

•U+1F440 EYES
•U+1F441 EYE
•U+1F444 MOUTH

■7 Searching

I find the description about the annotation in the 7 Searching, “Annotations are 
language-specific”. I agree with this description. For example, it is not easy for 
most Japanese people to remind the keyword “face” to mean the face of the clock. 
Therefore, it is reasonable to clarify that the emoji-annotation in the current draft 
is designed for English or a user group with particular cultural background.

Because the annotation in current UTR #51 assumes a particular language, it would be 
controversial to give a generic file name, “emoji-annotations”, without the name of 
assumed language. The file names should clarify the language that the annotations are 
designed for. As CLDR, giving the suffix by RFC 5646 would be considerable options. 
For example, “emoji-annotations_fr-FR” for French in France, “emoji-annotations_de-DE” 
for German in Germany, and “emoji-annotations_ja-JP” for Japanese in Japan. The file 
in current draft should be named as like “emoji-annotations_en-US”, if it is designed 
for English in US.

■Annex D

Some emoji characters in Annex D are described as the additional candidates for Unicode 
8.0 which would be released in mid-2015. This description is surprising, because Unicode 
Consortium wrote as no additional emoji characters would be added to mid-2015. 

In the liaison report to ISO/IEC JTC1/SC2 (, 
Unicode Consortium reported as following:

“For example, if a repertoire for Amendment 1 has passed a DAM ballot with comments resolved 
at WG2 #63 in Colombo, then it will be possible to include that repertoire in Unicode’s 
2015 release. But, Amendment 2 would not be considered for Unicode’s 2015 release since 
it would not be stabilized by January 2015”.

In the latest ballot text for Amd.2, EMOJI MODIFIERS are included. Therefore, EMOJI 
MODIFIERS should not be considered for Unicode 8.0 in 2015 release. In fact, Amd.2 is 
not stabilized yet, although January 2015 is ending soon.

Besides, the draft of UTR #51 includes the candidates of additional emoji characters 
that are never proposed to ISO/IEC JTC1/SC2/WG2. WG2 N4635 and UTR #51 are inconsistent, 
and difficult to review. The second public review of UTR#51 is required after solving the 

I have no objection to consider further additions of new emoji characters, but it should 
not be described as the candidates for Unicode 8.0. They should be discussed as the 
candidates for Unicode 9.0.


I am a journalist. I published the following articles about emoji during these several months.

•2014-10-7: INTERNET Watch: 絵文字に平等をサポートしてください」人種差別の指摘にゆれるUnicode 
•2014-11-28: INTERNET Watch: どんな人々がUnicodeの絵文字に「民族の多様性」を求めているのか? 

I will be happy if you add my articles to your web page “Media Articles” (

Date/Time: Wed Jan 14 22:16:26 CST 2015
Name: OGATA Katsuhiro
Report Type: Public Review Issue
Opt Subject: Comment to PRI 286 part.2

The title element in the web page of UTR #51 is described with "UTS #51: Unicode Emoji". 
It should be "UTR #51: Unicode Emoji" definitely.

Date/Time: Thu Jan 22 12:05:32 CST 2015
Name: Michael Everson
Report Type: Public Review Issue

I am adamantly opposed to the addition of more anthropomorphic symbols or
pictographs (unless they are part of writing systems like Naxi Tomba). There
is absolutely no way to avoid somebody getting upset about the depiction of a
person, demigod, or deity, whether the character embodies a cosmic principle
or what. The DHYANI BUDDHA is particularly problematic as there are really
FIVE of them, not one. It is in fact misleading to encode one as though it
were a generic category.

Political correctness in names is wearisome. Regarding PLACE OF WORSHIP, I
find it irksome that this is being added in order to provide users with an
emoji syntax. This is language engineering, not character encoding. It is
outside the scope of the standard to do that sort of thing. A symbol like this
should be added as a Map Legend character, and should be supported by
documentation as to the glyph variants of such a thing. With regard to the
Review Note... well, WORSHIP and MEDITATION are not really the same things.

Date/Time: Fri Jan 23 11:17:17 CST 2015
Name: Alexei Chimendez
Report Type: Public Review Issue
Opt Subject: Technical Report #51 -- Unicode Emoji

(1). In the currently proposed 'emoji-ordering' document the glyph U+1F47F IMP
is placed with the majority of glyphs in the 'Emoticons' block. I presume the
reason for this is Apple's implementation, which depicts IMP as an angry
counterpart to U+1F608 SMILING FACE WITH HORNS.

Apple's implementation (and by extension, Twitter's implementation, which
follows Apple's) is flawed in this regard; all other major implementations,
including Android, Windows, Samsung, KDDI, and Softbank, use a distinct
'fairy-tale' appearance, consistent with the Unicode Consortium's reference
implementation for this code point.

If there is a need for such a 'ANGRY FACE WITH HORNS' it should be added
seperately, rather than hijacking the code point for IMP.

The logical place for IMP would be within the range that encompasses the other
'fairy-tale' character glyphs, which currently composed of JAPANESE OGRE

(2). The currently proposed order for the codepoints U+1F31A through U+1F31D
MOON WITH FACE) is seemingly arbitrarily interjected by the glyphs

It would make sense for the MOON WITH FACE glyphs to follow the same order as
the MOON SYMBOL glyphs (those without face).

(3). The reference implementation for the Emoji Candidate 'THINKING FACE'
features not only a face, but also a thought balloon. Existing
implementations, such as the one in Gmail[1], do not feature such a balloon.
Furthermore, the balloon is already encoded at U+1F4AD. The face should be
separated from the balloon to allow for both use cases with and without


Date/Time: Fri Jan 23 14:33:07 CST 2015
Name: Andrew West
Report Type: Public Review Issue
Opt Subject: Dhyani Buddha

The DHYANI BUDDHA emoji character proposed for inclusion in Unicode 8.0 is
problematic for several reasons, and should be excluded from encoding.

1) Emoji representations of gods, demi-gods, sons of god, prophets of god, or
indeed any deity or personage worshiped or revered by religious communities,
may be considered offensive by some members of such communities, especially if
the depiction appears disrespectful due to the cartoonification or
emojification of the image.  Even if the representative glyph in the Unicode
code charts is carefully selected to minimise offense, the Unicode Consortium
and ISO have no control over font implementations (as has been amply
demonstrated by racially problematic emoji implementations of characters
representing human figures), and the Unicode Consortium and ISO may be held
responsible for comic or offensive implementations of characters representing
religious figures.

2) Encoding the Dhyani Buddha character sets a precedent for encoding an open-
ended set of religious figures.  There are five Dhyani Buddhas (wisdom
buddhas), and yet only one of them is proposed for encoding, thus inviting
encoding of the other four Dhyani Buddhas, or indeed any of the large number
of buddhas, bodhisattvas and arhats recognised in Buddhism.  And if Buddhist
figures are encoded as characters, then why should not deities and other
figures recognised by all other religions by encoded if requested?

For these reasons I suggest that no characters representing deities or
historical persons should ever be encoded.

Date/Time: Sun Jan 25 17:17:53 CST 2015
Name: Addison Phillips
Report Type: Public Review Issue
Opt Subject: I18N-ISSUE-397: Interaction of variation selectors and proposed emoji modifiers

The W3C Internationalization Working Group has reviewed UTR#51. This
submission is one of two issues that the working group is submitting. The ID
at the start of the subject line is used to track this issue in our tracker

This issue is:

We can't find any mention about how variation selectors and emoji modifiers
interact (canonical order, etc.). This information seems important to proper


To contact the I18N WG, please reply to or to www- You can also reach us through your liaison to us (Mark

Date/Time: Sun Jan 25 17:19:16 CST 2015
Name: Addison Phillips
Report Type: Public Review Issue
Opt Subject: I18N-ISSUE-405: clarify embedded image vs. character (editorial)

The W3C Internationalization Working Group has reviewed UTR#51. This
submission is one of two issues that the working group is submitting. The ID
at the start of the subject line is used to track this issue in our tracker

This issue is:
Section 1 (Introduction)

There is this sentence:

Emoji may be represented internally by embedded images or as encoded 
characters, called emoji characters for clarity.

This doesn't actually clarify what "encoded characters" or "emoji characters"
means here. Some illustration or further explanation is probably wanted. Also,
"internally" is slightly misleading. Would it be better phrased as:

Emoji may be displayed as (sometimes quite colorful or even animated) 
graphics or they may be represented by normal glyphs encoded encoded 
in fonts like other characters. These latter are called emoji characters 
for clarity.

To contact the I18N WG, please reply to or to www- You can also reach us through your liaison to us (Mark


SEE ALSO: L2/15-006, Comments on PRI #286, Proposed Draft UTR #51, from C. E. Whitehead.

Date/Time: Wed Nov 5 12:14:44 CST 2014
Name: Shawn Steele
Report Type: Feedback on an Encoding Proposal
Opt Subject: Reaction to colors

I like the idea of addressing variety, but my immediate reaction was that I'm
not there if I've been skiing/sailing/etc as there's no red!  (I confess my
2nd thought was neither is my son if he's been sailing as there's no green)  I
know that sounds kinda silly, but the proposed coloring seems limited to me,
ESPECIALLY for emoji, where people are "over the top"

Additionally, my son is probably more concerned about hair color.  That made
me take a closer look at the "heads".  There are notable things, like no

The colors are being added as combining characters, which makes me wonder
about doing the whole thing that way?  Face + Happy + Woman + Yellow hair +
Police hat?  Yea, where's the line & all that, but there'd be far more
flexibility, and if the were added as overlays, maybe not so hard to implement
in a font.

Date/Time: Fri Jan 30 14:18:11 CST 2015
Name: R S
Report Type: Public Review Issue
Opt Subject: UTR #51 and L2/14-213

I support's efforts to provide diversity as proposed in

While not perfect, it is a much needed first step towards eliminating 
limited representations of human diversity.

Palo Alto

Date/Time: Sat Jan 31 07:42:22 CST 2015
Name: OGATA Katsuhiro
Report Type: Public Review Issue
Opt Subject: Feedback to UTR #51 part.3

The source of U+1F60E is described as Japanese carriers a table of 
"Major Sources".  This is a mistake. A source of U+1F60E is Gmail. You 
should replace samplecharacter with different character.

Date/Time: Tue Feb 3 10:46:18 CST 2015
Name: John Cowan
Report Type: Feedback on an Encoding Proposal
Opt Subject: Proposed Emoji from Lojban

I am personally (not as a representative of any group) proposing the following
concepts for emoji.  All are drawn from the Lojban gismu list.  None of them
appear in the 8.0.0 UnicodeData draft 7, nor in tranche 5 revision 2

Plants (mostly edible and/or consumable): barley, buckwheat, cabbage, cassava,
cork, garlic/onion/other bulbs, grass, hemp, lotus, millet, mold(y), moss, nut
(generic), oak, oats, rye, sorghum, soya, tobacco, wheat.  Some of these may
be too similar to others.

Animals (edible and/or domesticated and/or metaphorically significant, or
products thereof):  bear (not bear face), butterfly, cockroach, deer, donkey,
egg, feather, fig, fly, fox, goose, lion (we have tiger), louse, turkey, wolf,
wool, worm.

Please acknowledge receipt of this.

Date/Time: Tue Feb 3 12:38:30 CST 2015
Name: Markus Scherer
Report Type: Public Review Issue
Opt Subject: PRI 286 PDUTR #51, Unicode Emoji: collation

About section 5, Ordering and Grouping: I have said this before but am not
sure if I added it to the record:

In my opinion, while I agree that the DUCET order of emoji symbols is not
good, I think there is low or negative ROI for this.

I think there is low value: I don't see users caring about the order among
symbols; AFAIK collation bug reports are only ever about letters (plus
combining marks etc.). Strings consisting only of symbols are not normally
sorted, so the order of symbols only makes a difference when comparing strings
that contain words/names and differ only by symbols. This is very uncommon.

There is a cost: Development, review, feedback, maintenance, BCP 47 keyword,
size of the collation rule string and of the binary data generated for it.

I just added this to but
PDUTR #51 requests feedback via this form.

Date/Time: Tue Feb 3 12:53:49 CST 2015
Name: Markus Scherer
Report Type: Public Review Issue
Opt Subject: PRI 286 PDUTR #51, Unicode Emoji: palettes

Section 6 Input: I suggest adding a note in this section that palettes may
show the same symbol in multiple categories, because some may be ambiguous,
and it is not necessary for an emoji to be in a unique category. In ambiguous
cases it would help users to be able to find a symbol in multiple categories,
wherever they may reasonably look.

emoji-labels.html already says "Characters may occur more than once."

Feedback above this line was discussed in UTC #142, February 2015. The PRI is now closed