by Michael S. Kaplan, published on 2010/04/27 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2010/04/27/10002948.aspx
At first I was U+1f600, content to realize that Unicode would never encode the Emoji, especially after so openly dismissing competing attempts at standards that included emoticons "needed by regular people in common chat-type scenarios."
After that I was U+1f634, sleeping off the celebratory drinks afterward.
Suddenly I was awake and U+1f62e, assuming I must have heard wrong.
I decided to be U+1f62f, and wait for people to repeat themselves.
Then I was U+1f615, when people were clearly continuing to talk about the Emoji.
As it continued I was U+1f61f; could it really be happening?
As the Emoji progressed, I was U+1f62c; what else could my reaction being during such turmoil?
As things got further along, I was an inconsolable U+1f611, as I found that food didn't even taste like food anymore.
And then the email from Peter came, telling me that:
The proposal to encode Emoji characters in Unicode / ISO 10646 progressed to the last stage in the standardization process last week. At this point, the character repertoire and code positions are fixed. Final documents are still being prepared, but you can the new characters (along with other new characters being processed together) in this doc:
http://www.dkuug.dk/JTC1/SC2/WG2/docs/n3838.pdf
Changes to the Emoji repertoire at last week’s meeting included
- Various changes to character names and representative glyphs
- Addition of one new emoticon
- Re-organization of the Emoticons block (changed code positions)
- Some changes in the EmojiSrc.txt mapping data
I couldn't even remember the name of the Bytext guy, but I am sure if he knew of all this, he would be quite U+1f61b about all of this, saying "Tonight I will go home and U+1f619 my wife, think about question #3 in the Bytext FAQ, and yell out the window at the top of my lungs: I TOLD YOU SO!!!."
Thankfully, Peter mentioned 13 additional emoticons that were accepted for some later version of the standard:
1F600 GRINNING FACE
1F611 EXPRESSIONLESS FACE
1F615 CONFUSED FACE
1F617 KISSING FACE
1F619 KISSING FACE WITH SMILING EYES
1F61B FACE WITH STUCK-OUT TONGUE
1F61F WORRIED FACE
1F626 FROWNING FACE WITH OPEN MOUTH
1F627 ANGUISHED FACE
1F62C GRIMACING FACE
1F62E FACE WITH OPEN MOUTH
1F62F HUSHED FACE
1F634 SLEEPING FACE
with their glyphs as shown in document N3834.
If he had not mentioned these to-be-encoded characters, this blog would not have had nearly as much emotional structure.
Let's face it, I am not that organized!
Come to think of that, I could have used these ones like a month and a half ago!
ErikF on 27 Apr 2010 11:51 AM:
Can you ship an IME for this in the next version of Windows? It would work great with the qps-l33t locale that obviously should be there as well! :-) (U+1F601).
Seriously, some of these proposals are getting really strange. Having dingbats is one thing, but playing cards and cat faces? What's next, clipart? No wonder they needed to up Unicode's code point coverage to 32 bits!
Michael S. Kaplan on 27 Apr 2010 12:25 PM:
I agree, and have trouble with the entire block. Mostly we all did, before I left, with only a few seeing merit in the proposal with lots of conceptual problems....
Hiroshi on 27 Apr 2010 3:08 PM:
I too watched this develop on the Unicode list.
While I am a daily user of emoji on my Japanese cellphone, I am rather opposed to this "encoding". This is wrong on many levels. Those reasons have been enumerated too many times to repeat.
It only made it through because of strong company support from Google and several large Japanese telecommunication companies. (Each Japanese cellphone company has been supporting basic mappings of each others private emoji set for several years now.)
If it was the same proposal without the large corporate support it would never have made it out of initial discussion.
Cheong on 27 Apr 2010 6:07 PM:
Sorry to by out of topic. But I think you may have a clue on my question.
I found that my Vista PC have suspicious update today. The update is said to be related to "remove WPF from Windows Font that cause problem in Office 2010 installation". But aren't new font also be installed in Office 2003/2007? It should have caused problem earlier. Or is that Office 2010 will install some new font rendering engine so it hit some problem not experienced by earlier Office installations?
Anyway I'd also find the timing strange... It's not security related issue, and is a product support one. Isn't it Microsoft's policy to make it available through product support on request first, then deploy it through "Tuesday update"?
Thanks a lot.
Random832 on 29 Apr 2010 4:29 AM:
"Having dingbats is one thing" - but isn't this precisely the same thing, though? The basic 'urge'* of Unicode to encode everything that anyone has ever used characters to represent - which is the only thing that can ever explain the whole of the dingbats block [esp. considering its strong bias towards right-pointing arrows that can only be explained in terms of the pre-existing Adobe Zapf Dingbats character set] is entirely sufficient to account for this.
Michael S. Kaplan on 29 Apr 2010 9:16 AM:
Hey Cheong -- not really related in any way whatsoever. :-( Maybe you wanted the Suggestion Box?
Michael S. Kaplan on 29 Apr 2010 9:17 AM:
Hey Random832 -- the Dingbats came in under another principle -- that of the encoding of legacy data in other character sets. This is new stuff and many people agreed with Hiroshi's take, both inside and outside of Japan....
referenced by