Remix.run Logo
▲ rmah 5 hours ago

Personally, I think adding emojis to UNICODE was a mistake.

▲sixtyj 2 hours ago | parent | next [-]

Imho Unicode is the only accepted universal system how to sustainably maintain emoji… recent and all future ones.

Unicode has over 1.1 millions of coding points and it is allocated space ~16 pct only.

All alphabets’ characters are described, all emojis are in… and you still have 800,000 positions available for future.

There are more than 300,000-400,000 fonts and everybody with FontMaker can make another fork/copy/enhance “basic” sans or sans-serif fonts…

…and all of them use Unicode as base.

U+1F600 for smile. :)

Edit: TIL that empty square used in a font for non-existing representation of Unicode character is called tofu :) □

▲Gigachad 3 hours ago | parent | prev | next [-]

I feel like it would have been better to just allow embedding a small arbitrary bitmap or vector image in text. No one likes the current state where you send an emoji that looks one way on your system and then looks different on the receiving end. And it would have avoided all the conflict over which emojis get added and which don't.

▲egnehots 2 hours ago | parent | next [-]

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.

▲sixtyj 2 hours ago | parent | prev | next [-]

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.

▲whatshisface 2 hours ago | parent | prev [-]

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

▲Animats 2 hours ago | parent | prev | next [-]

Does anyone still use emoji? Except for ones on forum replies. I sometimes get an emoji as a one-glyph reply to texts. That's about it. They were far more popular a decade ago.

▲Aerroon an hour ago | parent | next [-]

Isn't this expected? It's always been custom emotes everywhere. Even before emojis, the "default emoticons" fell out of favor among avid users.

▲rwmj 2 hours ago | parent | prev | next [-]

Antiquated symbols used in historical texts is something I approve of in Unicode.

▲eastbound 2 hours ago | parent | prev [-]

Marketing copy and job offers are full of them, and AI has made that much more frequent. I assume you include all kind of pictures punctuating sentences, such as "someone at a computer" when you mention working, etc., not just yellow faces.

▲dataflow 4 hours ago | parent | prev [-]

Why?

▲saulpw 3 hours ago | parent | next [-]

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.

▲p-e-w 2 hours ago | parent [-]

> They are not part of any existing writing scheme

They are today, and there is now orders of magnitude more writing that uses emoji than the entire corpus of many of the scripts covered by Unicode.

Language and writing have always been continuously evolving and that process didn’t magically stop when the Internet was invented. The first emoji preceded their inclusion in Unicode, humans used them in writing, therefore they belong in Unicode.

▲saulpw 22 minutes ago | parent [-]

Let me put it another way: Unicode is for letters, not for words.

▲ninjin 3 hours ago | parent | prev | next [-]

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

▲eviks 2 hours ago | parent [-]

> I usually propose that we unify the common subsets of the Cyrillic, Greek, Latin, and Mathematical glyphs which usually finally drives home the point.

That would be an awesome compact encoding scheme (and also help with the next 4million emojis)! And given the relatively higher importance of those CyrGrLat, it would force wider proper support that would resolve the issues you raised, which are all app-dependent

> But, they are invisible to the end user

Apps make them visible, some even do that for whitespace chars to highlight the difference

> can disappear while copying and pasting

broken clipboards can be fixed? They somehow manage to retain rich text formatting, surely they cna retain language markers?

> you have to rely on the original author even putting them there in the first place!

Nope, the author's input app can handle that just like the original author doesn't need invisible joiners to use composed emojis

▲bigstrat2003 3 hours ago | parent | prev [-]

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.

▲hnlmorg 2 hours ago | parent [-]

So what about ASCII control codes? They are non-printable characters that are part of Unicode, grandfathered in, yet aren’t part of any writing systems.

And home computers have had pictograms as part of their character set since the late 70s/early 80s. For example code page 437 (MS-DOS) had smilies, card suites, and other emoji. Likewise for the PETSCII (Commodore Pet) too.

And not just emoji’s, but full on drawing characters. In fact that was the only way to draw graphics on some early systems, such as Teletext, in the early 70s.

And then you have the question of what pictograms are part of writing systems. For example the media control symbols (play, pause, fast forward, etc). Or how about the fact that some emojis had been part of written text long before Unicode, in the form of “smilies”, eg :-)

I hope this illustrates that the problem was never an easy one to define boundaries for inclusion.