From: Ken Whistler (kenw@sybase.com)
Date: Wed Mar 02 2011 - 16:20:59 CST
On 3/2/2011 1:29 PM, vanisaac@boil.afraid.org wrote:
> From: Leo Broukhis (leob@mailcom.com)
> --------------------------------------------------------------------------------
>> Unless a /Japanese/ phone provider adds it to the repertoire of symbols.
>>
>> Leo
> Actually, since these are compatibility characters, you'd need TWO phone
> providers to add it to their repertoire of symbols. There are no compatibility
> issues in a single repertoire.
Actually, that isn't the case. There are plenty of characters in the
core emoji
set which only occurred in a single Japanese phone provider set.
The compatibility issue is not the cross-mapping between the providers, but
rather the need for having a Unicode code point to represent each of the
existing SJIS extension characters for emoji used by *any* of the Japanese
phone providers.
> I'd like to see a note in the Emoji code charts
> that identifies the emoji/emoticons as compatibility characters in order to
> help preempt these sorts of proposals.
>
This has been clear all along in the discussions which led up to the final
encoding of the core emoji set.
But labelling a particular set of characters as "compatibility
characters" in the code
charts won't actually accomplish anything in terms of preempting proposals
to extend one group or another of symbols on semantic or functional grounds.
Each such proposal will end up having to be evaluated on its own terms,
based
on the argumentation and examples provided with proposals.
The point that Asmus was making (among others) is that the Unicode Standard
(and 10646) don't encode *images* as characters just because somebody can
demonstrate some conventional meaning associated with them, or because
somebody
claims some concept associated with an image as a "meme". Proposers need
to do the work to demonstrate the use of them as *symbols in text*.
That demonstration was easy for the core emoji set, because they already
existed
as encoded characters in SJIS extensions to character sets already
implemented
as text on devices. That demonstration was independent of anybody's a priori
determination of whether any particular pictographic symbol in that set
*should*
have been used as an encoded character. They *were* used as encoded
characters,
just like the original happy face from Code Page 437, lo these many
years ago,
and the Unicode Standard had to encode them and get on with it.
Proponents of a "facepalm symbol" would just need to get to work to: a.
demonstrate
the existence of a conventional pictographic symbol of some sort for it,
used
as a *symbol in text*, and b. demonstrate an implementation need for
encoding
it as a character in the Unicode Standard. The same kind of work that
proposal writers do for other kinds of symbols and/or scripts proposed
for encoding.
--Ken
This archive was generated by hypermail 2.1.5 : Wed Mar 02 2011 - 16:23:34 CST