Submitting Emoji Character Proposals
unicode.org
unicode.org
In 15 years, we'll be wondering why Unicode is clogged with so many stupid symbols.
I don't hate Emoji or anything, but it just seems unnecessary as part of the Unicode standard. Standards don't have room for creativity like this, if that makes sense...
Standards not Exuberances.
We could just create a WingDings-esque font for containing all of this stuff. It would be better to incorporate multi-font support into more devices rather than incorporate informal symbols into Unicode.
I am aware of the massive number of symbols represented in Unicode, but it seems that the vast majority of them are related to existing languages, or other symbols that are used in government. Not 400 different smileys of every race, and cats...
Edit: By creativity, I mean that Unicode is about expressing language and officially-recognized symbols. Incorporating art into it is contrary to the purpose of Unicode.
Some of the dead languages in Unicode arguably were never "real" languages and history disputes if they were actual written forms for a language or merely local doodles. Their relevance to Unicode is apparently there is so much academic work still trying to sort out said history that papers are written all the time with those dead symbols. (For all we know, some of them may even be ancient emoji. :P )
The difference between "formal" and "informal" is a fuzzy zone. It's almost like we're making up all of language as we go along. Unicode seems like a fine place to standardize our growing need for emoji. Also, for what it is worth, all of WingDings is also in Unicode and has been since early on.
My only criticism with emoji in Unicode is that I do think it means that Unicode should reconsider its stance on previously closed proposals for constructed languages like Klingon and Tengwar and maybe dedicate a section somewhere outside of the basic multilingual plane (BMP) for them.
If you think emoji is an expressive language, then I'd like you to make an argument toward that point in emoji.
1. Emoji only typically exists in the written form, but that isn't really a strike against it: paragraphs, capital letters, and (to some extent) word-breaks only exist in the written form too.
2. They have a conceptual existence, and communicative force, that is separate from any particular representation. You can't copy-write the smiley grapheme. You could copy-write a particular smiley image (or "graph"), much like you could copy-write a glyph, but that's it.
Finally emoji is important for many young children in Japan and China, (I'm not an expert on this). The issue is learning all the characters needed to express yourself is pretty hard and takes years longer than learning the latin alphabet. Further learning how to input characters on a computer takes even longer. However kids still want to communicate with each other and as a result use a lot of emoji to speed up the process for them. For them emjoi is how they want to express themselves.
The problems with a specific font for extra characters are: who would standardize it? And (assuming Unicode) how would they be represented in code points? You could use Unicode's Private Use Areas,[0] but from my understanding that might result in different characters viewed for the recipient if their implementation overlaps yours.
(Well, that, and asserting a minimum shared base of symbols that each WingDings font is expected to have depictions for. I think that's a less important role, though; they could just as easily get away with shipping a "Unicode-official fallback emoji font" instead, that would backfill for any codepoints a particular OS's emoji font doesn't have.)
---
† Identifiers for the pictures themselves, not the concepts they represent. That's an important distinction, I think: there really isn't a difference in concept between U+1F601 'GRINNING FACE WITH SMILING EYES' and U+1F638 'GRINNING CAT FACE WITH SMILING EYES'—but they're different little pictures. Effectively, they're like an icon/logotype/mark, with each font giving you a different artist's treatment on that mark.)
It's certainly a hit in the West, though. Every social media outlet I see is flooded with various emoji. Clearly people are using them, and Unicode has plenty of space, so why not standardize? If anything, it will slow down the proliferation of emoji.
And what are dingbat typefaces if not emoji under an other name? Nobody cared when unicode added U+2701 UPPER BLADE SCISSORS and U+273B TEARDROP SPOKED ASTERISK.
The debate isn't about how to standardize the display of symbols on platforms, but how to allow the incorporation those symbols into everyday text.
Are you confused? U+2701 UPPER BLADE SCISSORS is a Unicode codepoint, it can most definitely be used "within regular text of another typeface".
> given the limited scope of dingbats symbols
There is no limited scope, dingbats is just stuff that's neither numbers nor "letters".
Just because nobody complained doesn't mean that it wasn't a problem.
A polluted standard makes it more difficult to implement the standard. In practice this is passed on to the user in performance and monetary cost, not in something more visible. The fact that you don't understand the problem is due to you not working with Unicode at a low level.
The amount of mind reading you believed you managed to accomplish from a setup and a punch line is pretty astounding. Maybe leave that to the magicians?
When you have examples of emoji being used to communicate on anything resembling the level of a real language, I'll buy that argument. But currently even synthetic languages like Toki Pona or Esperanto are capable of far more communication than Emoji.
Considering emoji are older than many of their users, that's one hell of an assertion.
> In 15 years, we'll be wondering why Unicode is clogged with so many stupid symbols.
Yes because U+1F32E TACO is so much stupider than U+27B0 CURLY LOOP, U+2554 BOX DRAWINGS DOUBLE DOWN AND RIGHT, U+1031B OLD ITALIC LETTER ERS, U+3375 SQUARE OV or fucking U+10472 SHAVIAN LETTER ICE
> I don't hate Emoji or anything
Yes, yes you do.
> it just seems unnecessary as part of the Unicode standard
It's part of messages, being able to display both regular text and emoji mixed together without requiring incompatible custom image embedding extensions is useful and convenient.
> Yes, yes you do.
Was this necessary?
Oh no you di'int just hate on my Shavian alphabet!
Unicode is supposed to express writing systems. The Shavian alphabet is a writing system, even if it isn't in widespread use. It's apparently used more than Klingon though, as Klingon isn't included due to lack of widespread use. If I'm wrong on this, maybe we can convince the SEI to include Klingon? :)
Also as far as people being against emoji - the document covers why [1]. Unifying things is nice, so you don't give a smiley emoji to one person only to have it rendered as a "flipping the bird" emoji by another vendor. It's to aid in communication due to the widespread use of emoji characters. I was initially against the addition of them but you know what? The argument is pretty solid and backs what Unicode is trying to accomplish.
We should leave all of that unicode space available for all these new extraterrestrials that will be soon visiting us.
Making emojis Unicode will significantly improve their handling.
...and significantly hurt the handling of foreign language characters.
I'd be happy to have a standard for emoji. I'd be happy to have a standard for interleaving emoji and text. What annoys me is that the standard for emoji has been mashed into the standard for characters as if they are the same thing. Mashing the two standards together means that people who only want to support characters or only want to support emoji have no guidelines for doing so.
If you don't understand why this is bad, it's probably because you don't understand type systems and the fact that emoji and characters are different types.
How so? Emojis are far simpler than much of Unicode used for various languages (no combining marks or complicated grapheme rules). If your program doesn't shred code points outside the BMP, then it handles Emojis just fine.
> What annoys me is that the standard for emoji has been mashed into the standard for characters as if they are the same thing.
So you think it would be better to create an alternative encoding to UTF-8/16/32 that allows mixing Unicode codepoints and Emoji codepoints, then get all platforms to support it, then also completely restructure all the text-shaping libraries which assume everything is a Unicode codepoint. Instead of focusing on things like better RTL support, while just assigning some codepoints to emoji which require no big changes in encoding or display.
> Mashing the two standards together means that people who only want to support characters or only want to support emoji have no guidelines for doing so.
They have the same guidelines that every font creator has been using for the entirety of the existence of Unicode; only provide glyphs for the code points you expect to be used, provide a nice box character for the rest. Most fonts have a few thousand glyphs, while Unicode has assigned hundreds of thousands of code points. Emoji are just a drop in that ocean.
> If you don't understand why this is bad, it's probably because you don't understand type systems and the fact that emoji and characters are different types.
Mathematical symbols and characters are "different types". However, the excellent Unicode support for math symbols has been instrumental in screenreader support for mathematical expressions, since they are often next to regular text. And as far as distinguishing between different kinds of characters, that's what the whole concept of formally defined Unicode character properties[1] is for.
[1]: https://en.wikipedia.org/wiki/Unicode_character_property
Hell, IME Emoji much improved awareness of and support for astral characters (MySQL only finally added support for those soon-ish after emoji officially got added to unicode), and I expect the same for non-atomic grapheme clusters since features using these (flags, skin tones & groups) got added to recent Unicode emoji. The fundamentally anglo-centric developer world had limited intrinsic reason to care for either before emoji were added.
Next step, RTL.
So much wasted time waiting for all those kilobytes to finish downloading...
This is of course a straw man which has nothing to do with my question. However, it's not actually clear what you mean.
If you mean that we could make small pictures of individual characters and send those, well that's exactly what text encoding is; it's an implementation detail whether we specify a character as a unicode code point, or a URI (possibly relative, to allow fonts as namespaces).
If you mean sending one big picture of a piece of text, well that's what already happens. Rather than using PNG, we can get better quality and compression ratio by using the "plain text" image format. This only works well when we know that the image only contains text, otherwise we lose a lot of quality (e.g. see http://www.asciiworld.com )