> and just displays the individual parts in a sequence and it makes no sense.

IIRC some earlier version of UTC 51 explicitly stated that the implementations of a particular version of Unicode absolutely should not try to show any sequences, not mentioned in the emoji-sequences.txt and emoji-zwj-sequences.txt, as a single glyph and must treat them as distinct graphemes. It apparently has been removed in the recent years so there is apparently now absolutely no guarantee of what visuals and when exactly you can expect.

Yes but we used to call them emoticons which was a bit clunky to pronounce so it's probably a form of https://en.wikipedia.org/wiki/Phono-semantic_matching

ಠ_ಠ

Apple's autocorrect is already awful. What could go wrong with sticking more AI in between two people communicating with each other?

:)-8--<

That's a simple hack that fixes this issue, good job.

But now you have many more issues,

if you use a bitmap, it will look pixelated sometimes, some people love to zoom over text at incredible levels. What about light/dark themes?

If you use vector graphics, then which kind of them? will you use quadratic beziers, allow cubics? And don't think that it is easy to render vector graphics efficiently, there are many issues, parsing, anti aliasing, performance, you are also adding a new security nightmare, a good attack vector with complex to handle, parse untrusted user input.

And boy, we didn't even talk about caching, when will you send those payloads? when you type one emoji? Then what about the 2nd time? Surely not? Then how do you know the receiver has not lost your first payload? Should you batch send most payloads at the beginning? Will that introduce latency? Will you be hated by future generations?

Decoupling meaning, intent from representation, implementation is a good idea from text encoding schemes. We should not lost it. Fonts are a perfect example, most people are happy to use them. They do not overly complaint that you can change the way text is looking. The same meaning is sent to you, your platform text rendering stack is interpreting it and macos users are happy to have their consistent look, windows users are happy to have their ClearType legible rendering, ..well most are anyways.

Complex subjects rarely call for a simple hack. Yet I agree, emoji rendering is an issue. Some people even want to put in fonts rendering code (wasm?) because of how complex it is to handle.

Emoji is as font. And Unicode doesn’t store fonts, it describes character encodings.

And it is up to everybody how graphical representation of such encoding looks like.

Unique, universal and uniform encoding -> Unicode, in 1988 coined by Joe Becker.

The emoji plane represents the most censored, internationally accepted, committee-deliberated, and culturally sensitive image set in existence.

So you want the only widely accepted international text encoding to require including a whole image encoding standard too?

They are not part of any existing writing scheme. I think they could be a different standard like ":+1:" and ":chainsaw:" but it makes no sense for them to be built into text rendering.

Can not speak for the original poster, but I tend to agree in that it greatly limits the speed of creativity due to the integration process, creates a very subjective bureaucratic process for inclusion, and that frankly emoji are not a script (yes yes, you can make an argument that they are akin to ideograms, but this analogy breaks down rather quickly). Thus, I think a different technological solution could have been warranted. The story I keep hearing is that it was necessary to get the Japanese telephone companies on board with Unicode rather than their own emoji hacks combined with local Japanese encodings, which I can sympathise with as a necessary (but unfortunate) evil. A word of caution though that I find text with heavy use of emoji largely unreadable as my eyes fixates on the emoji rather than following the text; thus I am likely biased (but possibly still correct).

All things aside though, Han unification [1] remains the worst part of Unicode to me as it makes it impossible to know whether the glyph I am seeing is the one intended by whoever wrote the text (Chinese names in e-mails for example is an utter mess for someone like me that has to have their system set up to mostly handle English and Japanese). The whole Han unification mess more or less necessitates markup and sometimes even the insertions of raster image glyphs for historical and regional texts which is just bloody daft. Yes, Unicode language markers do exist and can resolve this in part. But, they are invisible to the end user, can disappear while copying and pasting, and you have to rely on the original author even putting them there in the first place! Whenever someone struggles to see the issue, I usually propose that we unify the common subsets of the Cyrillic, Greek, Latin, and Mathematical glyphs which usually finally drives home the point.

[1]: https://en.wikipedia.org/wiki/Han_unification

I think that Unicode should have been limited to only depicting existing writing systems. Anything else is imo out of scope for a text encoding format.