4 ms·

> Making emojis Unicode will significantly improve their handling. ...and significantly hurt the handling of foreign language characters. I'd be happy to have

> Making emojis Unicode will significantly improve their handling. ...and significantly hurt the handling of foreign language characters. I'd be happy to have a standard for emoji. I'd be happy to have a standard for interleaving emoji and text. What annoys me is that the standard for emoji has been mashed into the standard for characters as if they are the same thing. Mashing the two standards together means that people who only want to support characters or only want to support emoji have no guidelines for doing so. If you don't understand why this is bad, it's probably because you don't understand type systems and the fact that emoji and characters are different types.

johncolanduoni 11y ago
> ...and significantly hurt the handling of foreign language characters. How so? Emojis are far simpler than much of Unicode used for various languages (no combining marks or complicated grapheme rules). If your program doesn't shred code points outside the BMP, then it handles Emojis just fine. > What annoys me is that the standard for emoji has been mashed into the standard for characters as if they are the same thing. So you think it would be better to create an alternative encoding to UTF-8/16/32 that allows mixing Unicode codepoints and Emoji codepoints, then get all platforms to support it, then also completely restructure all the text-shaping libraries which assume everything is a Unicode codepoint. Instead of focusing on things like better RTL support, while just assigning some codepoints to emoji which require no big changes in encoding or display. > Mashing the two standards together means that people who only want to support characters or only want to support emoji have no guidelines for doing so. They have the same guidelines that every font creator has been using for the entirety of the existence of Unicode; only provide glyphs for the code points you expect to be used, provide a nice box character for the rest. Most fonts have a few thousand glyphs, while Unicode has assigned hundreds of thousands of code points. Emoji are just a drop in that ocean. > If you don't understand why this is bad, it's probably because you don't understand type systems and the fact that emoji and characters are different types. Mathematical symbols and characters are "different types". However, the excellent Unicode support for math symbols has been instrumental in screenreader support for mathematical expressions, since they are often next to regular text. And as far as distinguishing between different kinds of characters, that's what the whole concept of formally defined Unicode character properties[1] is for. [1]: https://en.wikipedia.org/wiki/Unicode_character_property https://en.wikipedia.org/wiki/Unicode_character_property
- masklinn 11y ago
  > How so? Emojis are far simpler than much of Unicode used for various languages (no combining marks or complicated grapheme rules). If your program doesn't shred code points outside the BMP, then it handles Emojis just fine. Hell, IME Emoji much improved awareness of and support for astral characters (MySQL only finally added support for those soon-ish after emoji officially got added to unicode), and I expect the same for non-atomic grapheme clusters since features using these (flags, skin tones & groups) got added to recent Unicode emoji. The fundamentally anglo-centric developer world had limited intrinsic reason to care for either before emoji were added. Next step, RTL.

johncolanduoni 11y ago

> ...and significantly hurt the handling of foreign language characters. How so? Emojis are far simpler than much of Unicode used for various languages (no combining marks or complicated grapheme rules). If your program doesn't shred code points outside the BMP, then it handles Emojis just fine. > What annoys me is that the standard for emoji has been mashed into the standard for characters as if they are the same thing. So you think it would be better to create an alternative encoding to UTF-8/16/32 that allows mixing Unicode codepoints and Emoji codepoints, then get all platforms to support it, then also completely restructure all the text-shaping libraries which assume everything is a Unicode codepoint. Instead of focusing on things like better RTL support, while just assigning some codepoints to emoji which require no big changes in encoding or display. > Mashing the two standards together means that people who only want to support characters or only want to support emoji have no guidelines for doing so. They have the same guidelines that every font creator has been using for the entirety of the existence of Unicode; only provide glyphs for the code points you expect to be used, provide a nice box character for the rest. Most fonts have a few thousand glyphs, while Unicode has assigned hundreds of thousands of code points. Emoji are just a drop in that ocean. > If you don't understand why this is bad, it's probably because you don't understand type systems and the fact that emoji and characters are different types. Mathematical symbols and characters are "different types". However, the excellent Unicode support for math symbols has been instrumental in screenreader support for mathematical expressions, since they are often next to regular text. And as far as distinguishing between different kinds of characters, that's what the whole concept of formally defined Unicode character properties[1] is for. [1]: https://en.wikipedia.org/wiki/Unicode_character_property https://en.wikipedia.org/wiki/Unicode_character_property

masklinn 11y ago
> How so? Emojis are far simpler than much of Unicode used for various languages (no combining marks or complicated grapheme rules). If your program doesn't shred code points outside the BMP, then it handles Emojis just fine. Hell, IME Emoji much improved awareness of and support for astral characters (MySQL only finally added support for those soon-ish after emoji officially got added to unicode), and I expect the same for non-atomic grapheme clusters since features using these (flags, skin tones & groups) got added to recent Unicode emoji. The fundamentally anglo-centric developer world had limited intrinsic reason to care for either before emoji were added. Next step, RTL.