Does each device send a code, interpreted by the recipient device/platform with its own library of images, or do devices send pictures, received as is? Or does it depend on the platform? Is there a standard?
It’s kind of both in practice. Emojis are codepoints in the vast character space of Unicode that are defined as “a drawing of an ant” or “a hand pointing up” or whatever. And it is perfectly easy for any modern device to render that codepoint in its own default emoji font.
But. If you visit a website that has its own emoji, such as Twitter or Facebook, then it’ll replace those codepoints with inline images.
The standard is Unicode. The ant is U+1F41C. I have mixed feelings about emojis in the Unicode standard. Apparently this is a Unicode character 'PISTOL':
How is this not a problem anymore? The Unicode standard spells out 'PISTOL'. Not 'WATER GUN'. They are just collectively not compliant to the standard. Why don't they just introduce 'WATER GUN' as a brand new code point and remove 'PISTOL' from their chat apps' emoji selection?
It might be a sad decision to make, but nothing was 'dumbed down'.
IMHO the 'correct' solution, if you want to remove the handgun picture is to remove it from the emoji keyboard (and possibly refuse to render it) and introduce a new water pistol emoji.
Besides, a small watergun graphic is just an often futuristic looking gun with neon colors. Hardly something that suddenly is unambiguously not a killing device.
I heard (but I may have misheard / misremembered) they're actually planning to remove that emoji from the standard.
It's an er, interesting position that the emoji standards committee (if that's the term) finds itself in. Do they have the right to determine discourse? There have been small riots (if that's the right term) about skin colors, genders, family composition, jobs, and now about weapons as well. They have the job (which I don't envy) to design an international language that is able to express a lot of concepts and emotions on the one hand, but on the other not to offend if possible.
And then there's the implementers, who have to add an extra layer to it - like the Apple crash bug which was caused by a certain flag emoji being available in one country but not the other.
>They have the job (which I don't envy) to design an international language that is able to express a lot of concepts and emotions on the one hand, but on the other not to offend if possible.
Why is their job to avoid offending anyone? Why a pistol emoji showing a real life pistol is offensive on itself? It's not like I can't offend anyone using only the ASCII character set.
I believe Apple led the way by changing the emoji to one of a water pistol, and other companies (most notably, those that primarily run apps) changed theirs to follow suit.
It's like a font. The webpage specifies "print the capital letter A in times New Roman font size 20". Your browser or app prints the letter as best it can.
Ok, very clear. But fonts have unique names that are relevant to the font itself. Times New Roman is Times New Roman everywhere; if you don't have the font it can be substituted with another font of the "Times" family or maybe just a serif font.
For emojis it seems every big company makes its own thing? instead of using libraries made by professional design shops / foundries like for fonts; that's confusing.
For fonts every big company does its own thing too. San Francisco is an Apple font you won't find outside their ecosystem. Arial, Courier New, Comic Sans, etc are Microsoft fonts (or popularized by being shipped on Windows 3.1). Roboto is a Google font and used by all their products.
It just happens that fonts are mostly handeled by operating systems providers while emoticons are mostly handeled by chat system providers. That has historical reasons since beautifully rendered emoticons were used as a selling point long before emoticons were added to fonts in the West (Japanese code pages did have emojis, so things might have developed different if chat was dominated by Japanese companies instead of American ones). Meanwhile providing custom fonts wasn't feasible for websites for most of the internets existance, so that hasn't caught on yet as something web-based companies like twitter do.
It's not that different from how a lot of international details are handled for fonts. As someone used to latin letters, you have a giant set of foundry-made fonts with cool names, interesting histories, and visible distinctions between families.
If you use a more complicated script such as Chinese/Japanese/Korean ideograms, or more rare script like Cherokee, you not only have fewer choices, maybe a font or three. In those cases those fonts are often more closely tied to the system manufacturer than what in the latin script world we'd think of as a foundry or type designer. Some scripts wish they could afford designers/type-foundries to explore playful variants like or similar to the vast variety we see of latin characters. (I've seen kickstarters/indiegogo campaigns for exactly that.)
Then there are Unicode fallback fonts. A font "Times New Roman" doesn't (and likely couldn't) include _all_ of Unicode. It's a big sea of characters. Not just because it would take a lot of work for every font to cover all of Unicode, but because for most fonts it doesn't even make sense. What's the difference between say "Arial" and "Helvetica" outside of latin/latinate letters? How would you apply that to CJK ideograms or Cherokee letters? So for a lot of Unicode codepoints, the systems all fall back to common system fonts (a dedicated Cherokee font, a rotation of CJK fonts based on all sorts of things like region and some rare hints from the font being falled back from).
It's possible for classic foundry fonts like "Times New Roman" to ship with full emoji sets, and to have outside font choices to shift emojis. The one non-technical question remains: what would that even mean for "Times New Roman" emoji versus "Arial" emoji, "Arial" versus "Helvetica"? It's possible we might figure out a use for something like a "serif" versus "non-serif" emoji and the fallback can send that as a hint of sort like some other scripts have, but never need anywhere near as wide a variety of emoji.
It's also possible systems could provide options of fallback emoji font based on user preference, if there were enough emoji font options. For now it's easiest for the system manufacturers to just bundle one and only one of their choice, such as they do with a script like Cherokee.
There are a few technical obstacles to allowing that. The big technical issue is how systems handle color rendering. Microsoft is currently to my knowledge the only system handling emoji entirely in the font rendering stack, with color data embedded as extensions into otherwise ordinary OpenType font files. [1] (Microsoft's emoji fallback font actually has a traditional foundry-style name, it is "Segoe UI Emoji", and can even be seen in font lists, not that it is that useful on its own as a latin font choice, and Character Map hasn't been updated to render color fonts nor show Unicode emoji ranges.) Many other systems have custom renderers that intercept Unicode emoji and replace with raster bitmaps of one form or another, rather than relying on "true" font fallback techniques.
As others have said, emoji are just unicode. What's interesting is that the some aren't just a single unicode character. For example, where skin tone is available for some emoji (e.g. Santa) it is represented as the generic emoji, plus a separate character representing skin colour. The client has to interpret this to show the intended glyph. Instagram engineering covered this quite nicely [1].
Emoji are characters, like 'a', '6', or '!'. But the thing about emoji is that most fonts don't include them, but many platforms (especially mobile platforms) provide a systemwide font that does, often in color. So any given emoji will look the same on the iPhone, irrespective of what font the surrounding text is in.
Does each device send a code, interpreted by the recipient device/platform with its own library of images, or do devices send pictures, received as is? Or does it depend on the platform? Is there a standard?