Closed GoogleCodeExporter closed 9 years ago
My initial reply on the emoji4unicode list:
On colors: We considered symbol colors for disunification but rarely for
character
names. Instead, with UTC guidance, we unified a number of symbols with existing
characters which have black/white/striped... glyphs and names. For newly
proposed
symbols, we followed the precedent and chose similar character names, matching
the
glyphs in the font that is being worked on.
On disunifications: At a glance, it looks like many of the suggested
disunifications
assume more specific and precise meanings and shapes than are intended by the
cell
phone carriers. For example,
- If a symbol generally looks like a crescent moon (e-014) and is described or
named
by the carriers to represent one, it makes little sense to give it a different
meaning based on an imprecise symbol shape. (What we can do is design a better
glyph.)
- If a carrier clearly intends a certain meaning, and shows that in name,
shape,
context of surrounding symbols and maybe other available information, we should
follow that meaning and not artificially invent a separate symbol and meaning.
(e-036
pisces vs. KDDI single fish)
- The carriers' understanding of "glyph variants", as expressed in symbol names
and
cross-mapping tables, is clearly broader than your sense of "glyph variants".
For
interoperability, we usually try to follow the carriers' cross-mappings, except
when
they are way off (as in e-7E0 subway vs. e-7E1 metro sign, which has been
discussed
by the UTC before).
Original comment by markus.icu
on 6 Jan 2009 at 8:45
Ken Whistler's reply on the emoji4unicode list:
> Quick comments on some Emoji symbols
> - Karl Pentzlin 2009-01-06
>
> Reference:
> http://www.unicode.org/~scherer/emoji4unicode/snapshot/full.html
> as of 2009-01-06
>
> The base for some of the comments are:
> - Symbols which are not merely glyph variants of each other should not
> be unified; if someone can address different semantics to two
> symbols they are different symbols, even when they are used
> interchangeably in the Japanese Telco context. When encoded in
> Unicode, the context is no more limited such.
I disagree. It is true that encoding a character for a symbol in
Unicode puts it in a context where it might not always be
limited to transcoding for the Japanese wireless sets, so that
due consideration must be given to how this is done. However,
when what we are encoding is a compability character for an emoji
which is *already* unified by de facto mappings between the
various carrier sets, it is not helpful -- in fact is disruptive --
to disunify glyph variants simply because the telcos use different
glyphs to display the cross-mapped character in question.
In such cases, as for the zodiac symbols which you wrote a
separate note on (and which Markus responded to), the correct
encoding solution here is to treat the cross-mapped emoji as
a *single* character for encoding, and then to either encode
a new single Unicode character (if no existing Unicode character
is appropriate) or to map to a single Unicode character if
one already exists -- as for the zodiac signs.
If a separate need occurs in the future to distinguish
animal-pictorial representations of zodiac signs, for example,
from traditional astrological symbolic representations of
zodiac signs, that needs to be done in a separate context
and be separately argued from the current emoji set -- because
separately encoding them on the basis merely of the distinct
glyphs used by the wireless carriers would *not* be a helpful
or useful solution to the emoji cross-mapping to Unicode problem.
> - Symbols should be named as they appear as emoji, not according
> to the black-and-white fallback glyph which is associated to
> them to print the Unicode charts. This means:
> · Symbols with an inherent color shall bear this color in their
> name unless the entity denoted by the name has identifies the color
> anyway (e.g., a BANANA is uniquely yellow and therefore does
> not need to be called YELLOW BANANA, while a RED APPLE must be
> named so as there are also green apples).
I disagree. This principle is simply not helpful. It perpetuates
the notion that colors are *inherently* a part of the character
identity here. And that does not serve the purpose of providing
a cross-mapping set for interoperability with the emoji characters.
It would be far, far better to simply have some abstracted
compability characters identified as EMOJI SYMBOL FOR BOOK-1,
EMOJI SYMBOL FOR BOOK-2, EMOJI SYMBOL FOR BOOK-3, etc., rather
than to insist on encoding RED BOOK SYMBOL, BLUE BOOK SYMBOL,
ORANGE BOOK SYMBOL, and then jump off the deep end in insisting
that the associated glyphs actually need to support color
distinctions.
> · Symbols which semantics include animation shall have ANIMATED
> as part of its name (this does not apply to symbols where
> animation is a feature of glyph variance only).
I disagree. This is the same issue as for the colored glyphs,
only more so. It is simply not helpful to insist that
"ANIMATED" be part of the character name, when that is a
description of the animated glyphs used on phones, rather
than a useful identifying label for the *character* we are
going to encode to represent the symbol in question.
> All symbol names are relative to any generic prefixes which are applied
> to the set of emoji symbols or subsets of it during the ongoing
> discussion.
>
> Any comment starting with "KDDI is", "DoCoMo is", or "SoftBank is"
> is a request to not unify this with the other symbols of the same row.
And I will simply put my comment in as opposing *all* such
disunifications across the board, without objecting to each
individual suggestion one-by-one below. I think this whole
approach is a very deep semiotic trap that completely
misconstrues both the problem and the nature of the solution
required for cross-mapping the emoji sets in Unicode.
> e-1A5 is MANS HEAD WITH LONG MOUSTACHE
> For reasons of political correctness, there must be two characters:
> DARK-HAIRED MANS HEAD WITH LONG MOUSTACHE
> BRIGHT-HAIRED MANS HEAD WITH LONG MOUSTACHE
> Otherwise, some traditional Bavarians which use to wear long blonde
> moustaches may be offended.
This is an example of the kind of dead end that this approach
results in. The problem here is to create a standard mapping
code point in Unicode for the emoji symbol listed at e-1A5.
The problem is *not* to solve some generic issue of how to
represent all races, skin colors, and masculine facial hair
styles politically correctly via character codes.
> e-1B6 KDDI is ANIMATED MALE DISCO DANCER,
> SoftBank is ANIMATED FEMALE FLAMENCO DANCER
That is another example of a completely unhelpful disunification,
as well as an example of the inappropriate application
of "ANIMATED" to a character name. The symbolic concept
being represented here is of a dancer. The glyphs chosen
on the phones to display that concept are animated and
designed differently. But encoding distinct characters and
making them overly specific to glyph designs is simply not
a useful direction to take for the character encoding for
the purpose intended here.
I could make similar comments one-by-one, but it should be clear
that I object to the complete set of comments in principle,
rather than just here and there on its details.
Original comment by markus.icu
on 6 Jan 2009 at 9:23
On reviewing these suggestions more closely, I agree with Ken that the
suggestions
are based on an overly pedantic interpretation of the carrier images,
disregarding
both common practice of naming Unicode symbols as well as the carriers' cross-
mappings.
Original comment by markus.icu
on 14 Jan 2009 at 5:39
Original issue reported on code.google.com by
markus.icu
on 6 Jan 2009 at 8:25