[christophclarke]

But in slack emoji, you have to modify the universal standard for the workspace in order to add those emoji, and now you're back to where you started.

The whole benefit of Unicode is that anyone anywhere can see Unicode on any device that supports it, without introducing added complexity of sending the actual image over the message.

[peterwwillis]

IIRC Unicode was intended to encode and represent text for writing systems. I get that the purpose of emoji in Unicode is to provide a universal way to represent certain pictures, but it's clear that we also don't want to be limited by the set of pictures we can send.

It seems a lot more sensible to actually send the picture you want to send, or a link to that picture, because that doesn't need to be interpreted differently by each client... just rendered. Sending the actual image might take more space in, say, a text message, but its actual encoded size should be pretty trivial. For example, one of Twitter's 16x16 color emoji is a 400 byte SVG file. Base64-encoded that would be about 533 bytes. The standard could define the image formats accepted, with probably one ideal format for emoji (SVG) and another for memes (JPEG).

Here's another way to think of how you could implement this in a standard. Each message is multipart. The text body is the first message by default. That text can contain references to other parts. That reference could be the name of the part you want to reference in that message, and that name would only need to be unique to that message. But that name could also be, for example, a SHA hash. When you accept messages, you could store the message parts in a database with their SHA hash. When someone sends the same part again in a new message, you can just retrieve that part from your database, rather than storing the same part multiple times. This could allow you to send messages referencing the same gigantic meme file 50 times, but you only ever store it the one time, and after that you just store references to it. The standard would allow you to simply say "please reference part X in this part of the message text, and if you don't have that part yet, here it is, base64-encoded or linked via URL".

(What I just described is MIME, but you could reinvent it if you wanted people to adopt it, because people don't like adopting things that aren't new and cool)

[masklinn]

> IIRC Unicode was intended to encode and represent text for writing systems.

Nonsensical garbage. The Arrows, Technical, Box Drawing, Block Elements, Geometric Shapes and Miscellaneous Symbols blocks were all part of Unicode 1.0.

> It seems a lot more sensible to actually send the picture you want to send, or a link to that picture, because that doesn't need to be interpreted differently by each client... just rendered.

1. Except now you need to design a way to design and render mixed content.

2. If that's your argument, why even have letters and fonts? Just send the right images.

[peterwwillis]

Uh, it's not nonsense or garbage, for multiple reasons. The first and foremost is that just because the first version supported arrows and geometric shapes does not mean it couldn't have been invented as an encoding for writing systems. The second reason is that I actually read what it was created for. https://www.unicode.org/history/summary.html The purpose was to encode the characters used by written languages for expressing language in a legible form. This includes multiple forms of graphemes.

Apps already have ways to render mixed content. How do you think you can see both text and pictures next to each other? E-mail has supported this for decades. The linked article even explicitly mentions how different apps render different image sets for the same emojis.

We have different fonts for several reasons, and sometimes we do send entire fonts in order to render our messages correctly. What font you use, and how you choose to render graphemes, is completely up to the application. What I'm proposing is a more interoperable way of sharing mixed content, which people clearly already want to do.