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?
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?
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.
Emoji are represented both as characters and as markup, and there's overlap.
(Markup is the correct approach, IMO, and I really need to finish my blog post on that...)
Emoji are a vital part of the way we communicate online so some see them as a prime way to push their agenda.
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.
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.
Sometimes you gotta break a few eggs to make change …
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.
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.
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.
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.
[1] https://docs.microsoft.com/en-us/windows/desktop/DirectWrite...
[1] https://instagram-engineering.com/emojineering-part-ii-imple...