From: Kent Karlsson (kent.karlsson14@comhem.se)
Date: Sun Dec 21 2008 - 17:41:58 CST
Below I’ll ignore the small set of bona fide characters in the
“emoji4unicode” document (those are either unifiable with
existing characters or are additions to some sets of already
existing Unicode characters).
There seems to be no real difference in principle between
“emoticons”, like the quite commonly used ones that are
listed (usually) in:
http://www.skype.com/intl/en/allfeatures/emoticons/
http://messenger.yahoo.com/features/emoticons/
http://messenger.msn.com/Resource/Emoticons.aspx
http://googlesystem.blogspot.com/2008/10/gmail-emoticons.html
and ”emoji” (even though ”emoji” just means ”picture
character”), like those in preparation to be proposed; here is
another list of some of them using black/white non-animated
images: http://pukupi.com/resources/emoji/.
So why are only the latter in preparation to be proposed?
The only difference *in principle* that I can see is that the
former are triggered by character sequences (of ASCII
characters actually), while the latter are triggered by PUA
codes. That’s it as far as I can see. Why the latter representation
would be a reason for encoding while the former is not eludes
me. Had the engineers working on the “emoji” chosen to trigger
them via character sequences (like for other "emoticons"),
for instance [RSP] or [やきいも] (perhaps prefixed with U+001B,
U+009B, or some "rare" graphical character so that accidental
triggering is unlikely) to get the “roasted sweet potato”
“emoji”, we would never have seen any work towards a proposal
to encode the “emoji” as characters, I guess. But if there is
an expectation that “emoji” supporters will move from the PUA
representation to a representation using standard dedicated
characters for them when “emoji” get such, why can they not be
expected to move to a character string triggering (i.e. a higher
level protocol)? The latter can be started right away. Or are
there preparations to encode also the “emoticons” (same
thing as emoji, really) from various vendors as individual
characters too? Expecting vendors/systems to change from
their current use of character sequence triggers (higher
level protocol) to use a dedicated character code per
“emoticon”?
So what’s next? Standardised characters for the striped bars
that are found in barcode fonts? Barcode fonts are quite
heavily used, but they are not Unicode fonts as there are no
Unicode characters for the stripe patterns. Barcode glyphs
are likely not used much for “texting”, but they have lots
of other uses. Also in web pages (you can see a 2d barcode in
http://pukupi.com/resources/emoji/, see
http://en.wikipedia.org/wiki/QR_Code).
/kent k
This archive was generated by hypermail 2.1.5 : Fri Jan 02 2009 - 15:33:07 CST