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 http://www.unicode.org/L2/L2014/14213-skin-tone-mod.pdf 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, etc. 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
Name: dujvayib@---.com
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 http://www.unicode.org/reports/tr51/#Diversity - retrieved on
2014-11-05
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
possible.
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 USA.
Date/Time: Fri Nov 14 17:02:14 CST 2014
Name: Doug Ewell
Report Type: Feedback on an Encoding Proposal
Opt Subject: BADMINTON RACQUET AND BIRDIE
Properly, this should be BADMINTON RACQUET AND SHUTTLECOCK.
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 dujvayib@---.com 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 favored. 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 Vehicles: • Motorbike • Quad bike • Forklight truck • Bulldozer and/or digger • Construction crane • Hovercraft • Fighter jet • Warship • Submarine • Tank • Satellite People: • Astronaut Sport: • Golf ball (the golf flag is too vague) All missing flags Modificatuons: • The gas/petrol pump [9981] should not have 'G' on it, making it language specific. Symbols: • 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. http://d.hatena.ne.jp/NAOI/20120730/1343641463 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”. •skin-tone-modifier •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 (http://isotc.iso.org/livelink/livelink?func=ll&objId=16835675&objAction=Open&viewType=1). ■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 •U+1F445 TONGUE ■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 (http://std.dkuug.dk/JTC1/SC2/WG2/docs/n4635.pdf), 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 inconsistency. 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. Postscript I am a journalist. I published the following articles about emoji during these several months. •2014-10-7: INTERNET Watch: 絵文字に平等をサポートしてください」人種差別の指摘にゆれるUnicode (http://internet.watch.impress.co.jp/docs/special/20141007_670150.html) •2014-11-28: INTERNET Watch: どんな人々がUnicodeの絵文字に「民族の多様性」を求めているのか？ (http://internet.watch.impress.co.jp/docs/special/20141128_678029.html) I will be happy if you add my articles to your web page “Media Articles” (http://unicode.org/press/emoji.html).
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
Opt Subject: DHYANI BUDDHA
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 through ALIEN MONSTER. (2). The currently proposed order for the codepoints U+1F31A through U+1F31D MOON WITH FACE) is seemingly arbitrarily interjected by the glyphs THERMOMETER and BLACK SUN WITH RAYS. 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 balloon). [1] http://mail.google.com/mail/e/35F
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 here: https://www.w3.org/International/track/products/66 https://www.w3.org/International/track/issues/397 This issue is: http://www.unicode.org/draft/reports/tr51/tr51.html We can't find any mention about how variation selectors and emoji modifiers interact (canonical order, etc.). This information seems important to proper implementation. -- To contact the I18N WG, please reply to public-i18n-core@w3.org or to www- international@w3.org. You can also reach us through your liaison to us (Mark Davis).
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 here: https://www.w3.org/International/track/products/66 https://www.w3.org/International/track/issues/405 This issue is: http://www.unicode.org/reports/tr51/tr51-1.html 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 public-i18n-core@w3.org or to www- international@w3.org. You can also reach us through your liaison to us (Mark Davis).
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 policewoman. 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 Unicode.org's efforts to provide diversity as proposed in http://www.unicode.org/reports/tr51/tr51-1.html#Proposals While not perfect, it is a much needed first step towards eliminating limited representations of human diversity. -RS/ 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 (L2/15-054r): 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 http://unicode.org/cldr/trac/ticket/7270#comment:6 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