@jetsoft

Yup, and you get things like Apple replacing the pistol with a water pistol, which lead to fun things like sending ‘I’m going to shoot you with a {pistol emoji}’ and Apple users receiving a playful message and everyone else receiving a death threat.

Unicode is intended to represent text and text has well-understood mappings to language. Often the glyphs map to many language (e.g. the Latin alphabet). This is even true for ideographic languages (Chinese characters are used by several spoke languages). But the key things are: you can communicate ideas using these glyphs as unambiguously as you can in a spoken language, and the mapping is well defined before they are recognised as part of an alphabet.

Unicode got a few emoji because a Japanese character set had them for their SMS messages. And that was perfectly fine because one of the goals of Unicode was that you should be able to losslessly round trip any prior encoding through Unicode. This meant Unicode had to be able to represent any existing character. There were a bunch of prior examples of these things being messy. For example, many 8-bit character sets had letters with accents. The canonical way of representing accents in Unicode is with a combining diacritic, but that can lead to ambiguity, so instead you map some random code page to the exact characters that it uses and then, when you don’t want to round trip it, you run the normalisation algorithm to get rid of the weird characters. All of this is to say: there was precedent in Unicode for characters that existed entirely for compatibility and should never be generated by anything not converting from an old character set.

But then they got carried away and added a fairly large and also incomplete set of little pictures. This caused a load of complexity in every part of the font rendering and text layout stack (font rendered have SVG renders embedded now!). At the same time, it added almost no value. Documents that mixed text and images were a solved problem 40 years ago. For bandwidth-limited applications, there were a bunch of compression schemes for common ones. MSN messenger 25 years ago defined a set of little pictures you could put inline and indexed them with short strings. Sending them required about as much bandwidth as a Unicode emoji in UTF-8. At the same time, you could also embed other images. Some HTML-based systems define custom URL schemes to refer to a table of common images that the protocol supports. Again. This gracefully decays to supporting images embedded with the message. There was one XMPP proposal to use a hash for image IDs and then send a request to the sender for the image if you hadn’t got a cached copy. This let each conversation have its own set of common little pictures, efficiently.

The phrase ‘custom emoji’ really highlights why this was a silly idea. There is no universal set of little pictures that covers the ones people want to send. People will always want more. But the Unicode space is finite.

In NSString and the surrounding infrastructure, OpenStep / Cocoa reserved one code point as a ‘attachment here’ marker with an out of band (via NSAttributedString) way of telling the text system what to put there instead of that character. Standardising something like that would have been more useful.