17 ms·

Some ideas of what to do with this space: - fully-customizable emojis (think of a RPG-like character customization screen) - heck, why not full jpegs/gifs? -

by mqus 13d ago

Some ideas of what to do with this space: - fully-customizable emojis (think of a RPG-like character customization screen) - heck, why not full jpegs/gifs? - some unicode programming script (running Doom) - ? That said, some very minor (HN-style) nitpick: > Otherwise for an n byte code unit this is (5n+1) / 8n, that is 5n+1 content bits out of a total of 8n bits from n bytes. We can rewrite this as (5/8) + 1/(8n) which moderately quickly approaches 5/8 = 62.5%. It is nice that this limit is nonzero and does not depend on n. Isn't a limit by definition no longer dependent on n?

jeroenhd 13d ago
U+E000–U+F8FF, U+F0000–U+FFFFD, and U+100000–U+10FFFD can already provide you with your own emoji, as that range has been reserved for private use. Extending the range further might make sense if you need even more space in your program, but that's a lot of space already.
- grumbelbart 13d ago
  The point is probably to encode the emoji (image) in the codepoint itself.
- mqus 13d ago
  2-3 bytes are not much space for anything. Sure, you could use multiple successive ones of these code points and define your own "continuation" encoding in these ranges, but that doesn't seem right to me somehow
  - flohofwoe 13d ago
    That combination is how it already works. You can build combined "characters" (grapheme clusters) from multiple code points, e.g. you could have a "base emoji" followed by a "modifier" emoji, and AFAIK that's how emojis with different skin colors work (one code point for the base emoji (e.g. 'thumbs up'), and a number of skin color modification code points which can be applied to all emojis that involve skin color.
xg15 13d ago
> some unicode programming script (running Doom) I agree with you that Unicode urgently needs a scripting capability (*), but my plan was to just implement it using invisible tag characters [1] or something like that - but of course allowing a script to be written in a single codepoint is the much more elegant solution. It also neatly solves the problem of how to write Unicode strings inside scripts inside Unicode strings and also scripts inside Unicode strings inside scripts inside Unicode strings. (*) in RFC 04-01-2027 [1] https://en.wikipedia.org/wiki/Tags_(Unicode_block) https://en.wikipedia.org/wiki/Tags_(Unicode_block)
- reaperducer 13d ago
  in RFC 04-01-2027 I, for one, welcome our new time-traveling overlords.
mqus 13d ago
One more idea: - Unicode-as-a-character, meaning: a whole text displayed as if it were one character, made for infinite zooming
sph 13d ago
Another one: encode instructions on how to draw the glyph into the text itself. The string becomes both the text and the font. Why not make it turing complete and as powerful/complex as TTF.
amelius 13d ago
Imagine someone using the same fully customized emoji multiple times in the same text. Seems like a waste of space. Maybe better to encode just a UUID, and send the image codebook separately.
Lockal 12d ago
> - some unicode programming script (running Doom) > - ? Bad Apple, oh, wait: https://github.com/hsfzxjy/Bad-Apple-Font https://github.com/hsfzxjy/Bad-Apple-Font

by mqus 13d ago

jeroenhd 13d ago

U+E000–U+F8FF, U+F0000–U+FFFFD, and U+100000–U+10FFFD can already provide you with your own emoji, as that range has been reserved for private use. Extending the range further might make sense if you need even more space in your program, but that's a lot of space already.

grumbelbart 13d ago
The point is probably to encode the emoji (image) in the codepoint itself.
mqus 13d ago
2-3 bytes are not much space for anything. Sure, you could use multiple successive ones of these code points and define your own "continuation" encoding in these ranges, but that doesn't seem right to me somehow
- flohofwoe 13d ago
  That combination is how it already works. You can build combined "characters" (grapheme clusters) from multiple code points, e.g. you could have a "base emoji" followed by a "modifier" emoji, and AFAIK that's how emojis with different skin colors work (one code point for the base emoji (e.g. 'thumbs up'), and a number of skin color modification code points which can be applied to all emojis that involve skin color.

xg15 13d ago

> some unicode programming script (running Doom) I agree with you that Unicode urgently needs a scripting capability (*), but my plan was to just implement it using invisible tag characters [1] or something like that - but of course allowing a script to be written in a single codepoint is the much more elegant solution. It also neatly solves the problem of how to write Unicode strings inside scripts inside Unicode strings and also scripts inside Unicode strings inside scripts inside Unicode strings. (*) in RFC 04-01-2027 [1] https://en.wikipedia.org/wiki/Tags_(Unicode_block) https://en.wikipedia.org/wiki/Tags_(Unicode_block)

reaperducer 13d ago
in RFC 04-01-2027 I, for one, welcome our new time-traveling overlords.

mqus 13d ago

One more idea: - Unicode-as-a-character, meaning: a whole text displayed as if it were one character, made for infinite zooming

sph 13d ago

Another one: encode instructions on how to draw the glyph into the text itself. The string becomes both the text and the font. Why not make it turing complete and as powerful/complex as TTF.

amelius 13d ago

Imagine someone using the same fully customized emoji multiple times in the same text. Seems like a waste of space. Maybe better to encode just a UUID, and send the image codebook separately.

Lockal 12d ago

> - some unicode programming script (running Doom) > - ? Bad Apple, oh, wait: https://github.com/hsfzxjy/Bad-Apple-Font https://github.com/hsfzxjy/Bad-Apple-Font