Accumulated Feedback on PRI #356

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: Thu Oct 12 15:36:08 CDT 2017
Name: David Corbett
Report Type: Error Report
Opt Subject: PRI #356: Extended_Pictographic is too broad

The proposed extension to Extended_Pictographic in 
for forwards-compatibility includes some symbols that are not likely to ever be emoji.

U+2686 to U+2689 are technical symbols used in go notation. They are not pictographs, 
so it would not be appropriate to add this property to them, which implies that they 
might be emoji one day.

U+1F540 to U+1F545 and U+1F900 to U+1F90B are technical symbols used in 
Typicon notation. They are not pictographs, nor are they the kind of popular 
symbol that gets used as a dingbat.

Feedback above this line was reviewed in the October 2017 UTC meeting.

Date/Time: Thu Nov 16 18:32:05 CST 2017
Name: Seigo Nonaka
Report Type: Public Review Issue
Opt Subject: PRI #356: Design Guidelines of unsupported emoji sequence

The proposed example of the indication for the unsupported emoji sequence located at the 
end of the "Section 2. Design Guidlines".

All of the examples, Cartouche, Stacked, Stacked Cartouche, Small Trailing, Bridging 
are not easy to implement in the major text layout engines. They may be technically 
possible but at least it is hard to implement on Android framework.

Please reconsider to include the current behavior, just shows an individual emoji, 
as an option of the unsupported emoji sequence indication.

Date/Time: Fri Dec 8 17:59:08 CST 2017
Name: Joel Bradshaw
Report Type: Public Review Issue
Opt Subject: Blonde hair explanation in UTS #51


I am excited about many of the changes in the most recent UTS #51 draft,
particularly those regarding guidelines around generic skin tone and gender.

I have a suggestion that is in line with other changes in this draft:
section 2.2 "Diversity", below the now-removed "gray as the generic skin
tone" illustration, contains the following wording:

"...dark hair is generally regarded as more neutral because people of every
skin tone can have black (or very dark brown) hair."

I recommend changing this to something similar to:

"...because black (or very dark brown) hair is widespread among people of
every skin tone."

The previous wording is suboptimal because it implies that some skin tones
*can't* have blond hair. While blonde hair is more common among some skin
tones than others, there are all kinds of variations, and I believe it does
occur with varying frequency in all skin tones. There are even populations
that very commonly have both dark Fitzpatrick-V skin and blonde hair, such
as Aboriginal Australians[1].

Thanks for all the good work,

Joel Bradshaw


Date/Time: Sat Dec 9 07:01:50 CST 2017
Name: Charlotte Buff
Report Type: Public Review Issue
Opt Subject: PRI #356: Standardizing Hair Style and Direction Modifier Syntax

The latest draft of UTS #51 introduces two new tools for modifying emoji:
Hair style and direction. These are realized with ZWJ sequences, so as usual
the UTC intends to publish a list of combinations that are recommended for
general interchange. However, these two mechanisms are clearly meant to be
generic and extensible by vendors or private persons, so it is useful to
define the proper syntax even when not all possible options are ever going
to be RGI. In particular, the UTC should define the exact ordering of

A fixed order is bound to break backwards compatibility with older sequences
eventually in some way or form, but we should not desperately try to
preserve archaic fallback display if it means we’re getting idiosyncratic
specifications and interoperability issues in return. Consider the two emoji
RUNNER and DANCER. RUNNER is an obvious candidate for directional sequences
and DANCER with different hair styles could be very popular with users, so
we might hypothetically include the following two sequences as RGI:

	β€’ Runner Pointing Right: πŸƒβ€βž‘οΈ (RUNNER, ZWJ, BLACK RIGHTWARDS ARROW, VS16)
	β€’ Dancer with Red Hair: πŸ’ƒβ€πŸ¦° (DANCER, ZWJ, EMOJI COMPONENT RED HAIR)

Later, however, there could also be calls for the inverse: RUNNER with hair
style and DANCER with direction. Naturally, both modifiers can be present on
the same emoji at the same time, but if we try to preserve the sequences we
have already added and simply push all additional modifiers to the end of
the stack we get the following situation:

	β€’ Runner with Red Hair, Pointing Right: πŸƒβ€βž‘οΈβ€πŸ¦° (RUNNER, ZWJ, BLACK RIGHTWARDS ARROW, VS16, ZWJ, EMOJI COMPONENT RED HAIR)
	β€’ Dancer with Red Hair, Pointing Right: πŸ’ƒβ€πŸ¦°β€βž‘οΈ (DANCER, ZWJ, EMOJI COMPONENT RED HAIR, ZWJ, BLACK RIGHTWARDS ARROW, VS16)

Devices that support the older sequences but not the newer ones will see
acceptable fallback display – a right-pointing runner followed by a hair
modifier, and a ginger dancer followed by an arrow – but the underlying
codepoints are inconsistent and unpredictable. One emoji has the arrow
before the hair and the other has the hair before the arrow. If we also add
gender modifiers into the mix there are already six technically valid
arrangements of modifiers, all of them identical in appearance but none of
them equivalent under any Unicode process.

The canonical ordering should try to group similar modifiers together while
also producing sensible fallback behaviour if an end user does not have
support for the full sequence. In my opinion the ideal order of modifiers is
as follows:

	β€’ Skin tone, hair style, gender/profession, direction

Skin tone and hair style both affect physical appearance, so they should
form one contiguous group. They must come before all others because
Fitzpatrick modifiers always directly succeed their base character. Next up
are gender modifiers and emoji used in professional sequences (e.g. 🌾 in
πŸ‘¨β€πŸŒΎ) since those also affect the fundamental appearance of the person, but
not anything about their body. Direction should be last because it makes the
least significant changes. Everyone would recognize horizontally mirrored
versions of the same symbol as indeed representing the same concept.

Using this approach arbitrarily complex combinations can be build up without
different vendors potentially using different sequences to encode the same

	β€’ πŸƒ (RUNNER)

Note that the hair (🦳) comes before the gender (♂️), even though the
gendered sequence β€˜πŸƒ+🏾+♂️’ was added to Unicode first. An older application
that is unaware of hair modifiers will thus not be able to form a male
runner but rather cancel the ligature after the Fitzpatrick character, but
in exchange for that the fallback rendering is much clearer. Consider a
farmer with default hair and with curly hair. The canonical sequence order
proposed here is as follows:

	β€’ πŸ‘©β€πŸŒΎ (WOMAN, ZWJ, EAR OF RICE)

The second example won’t look like a farmer unless the curly-haired sequence
is explicitly supported, but in fully unconnected form the meaning can be
deduced. β€œIt is a woman. After the woman is some curly hair in a dashed box,
so it’s probably meant to be a woman with curly hair. After that is a rice
plant, so maybe it’s supposed to be a curly-haired woman who does something
with rice.” If instead we tried to preserve the pre-existing sequence β€˜πŸ‘©+πŸŒΎβ€™
under all circumstances and tacked the hair (or any other modifier) onto the
end of the sequence, the curly hair would follow the rice plant (πŸ‘©πŸŒΎπŸ¦±), which
is a nonsensical construct and most likely harder to interpret for users who
don’t know how the ZWJ process functions. Imagine if Fitzpatrick modifiers
worked the same way in ZWJ sequences: πŸ‘©πŸŒΎπŸ½ instead of πŸ‘©β€ŒπŸ½πŸŒΎ.

If new kinds of modifiers are ever added in the future, their position in
the modifier stack should also be determined according to their function.
For example, let’s say we add an eye colour modifier. In sequences it should
come after hair style rather than at the very end because eye colour is a
physical characteristic of the human body and all body modifiers should stay

There are no expectations that any of this stuff is ever going to be RGI,
but the beauty of ZWJ sequences is that they are not bound by the limits of
the Unicode standard. Microsoft’s Segoe font includes over fifty thousand
family emoji; I wouldn’t put it past them to also add interchangeable hair
pieces to a wide array of characters, or allow the mirroring of each and
every asymmetrical emoji there is. Besides, anyone can design and distribute
their own fonts relatively easily nowadays. It’s better to set clear
guidelines now than having to deal with the fallout of mutually incompatible
systems cropping up all over the place because the specifications were too

Feedback above this line was reviewed in the January 2018 UTC meeting.