4 ms·

This is why I believe including emoji in unicode was a blunder. A capital "A" is the same in any font; I can write a message in monospace and my interlocutor ca

by qsort 2y ago

This is why I believe including emoji in unicode was a blunder. A capital "A" is the same in any font; I can write a message in monospace and my interlocutor can read it in sans-serif, or tap in morse code and have it rendered in hand- writing, in all cases the difference is immaterial. On the other hand we don't use pictures in the same way, the meaning of the message depends on the exact picture used as part of the "font". The whole thing about flags and skin tones are symptoms of the same problem.

kremi 2y ago
I’m pretty sure the thumbs up emoji or the slightly smiling emoji won’t get different interpretations based on font. And here the issue is not in font differences (or different pictures of the same thing getting different interpretations): it’s the thing represented that’s actually different.
- jorvi 2y ago
  In the earlier days of emojis, some Samsung or blob emojis definitely look different enough from Apple emojis that it caused confusion..
sangnoir 2y ago
> A capital "A" is the same in any font; I can write a message in monospace and my interlocutor can read it in sans-serif, or tap in morse code and have it rendered in hand- writing, in all cases the difference is immaterial Many typefaces are have problematic I/l/1 and O/0 characters, and that is material enough that applications avoid those characters entirely to avoid potential confusion. The problem is deeper than unicode: the fact that any codepoints can be rendered differently from client to client or typeface-to-typeface was always problematic, even back it was mostly ASCII.
ploxiln 2y ago
Even more, fonts having multiple colors in a glyph was a huge complexity explosion for font rendering, for terminals, and more. You can see a very quick technical summary of different ways of encoding colors in fonts here: https://en.wikipedia.org/wiki/OpenType#Color_fonts https://en.wikipedia.org/wiki/OpenType#Color_fonts But anyway, images should have remained separate things, png or whatever. Fonts rendering is complex enough with complex scripts e.g. Arabic, but that is the domain of fonts/shaping/rendering. Such a hugely expensive technical mess because people want their stupid color emojis.
- philistine 2y ago
  You want to stay stuck in the past, that's your call. I for one stay fascinated by the prospect of colour being introduced into written languages to denote intent now that we don't have to grapple with ink. We're talking on the scale of centuries, but even Arrival didn't have the guts to include colour into the lexicon of its alien language. With, of course, accessibility for those needing it.
  - deleted 2y ago
    [deleted]
  - yencabulator 2y ago
    You can use colors in your document or email without needing it to be in a font.
miki123211 2y ago
Even worse, the Emoji descriptions (on some platforms) don't correspond at all to what the emoji actually represents. For example, the " " emoji, described by Unicode as "health worker" is called "non-binary doctor" by Apple. If you send that emoji in a text to somebody, and they're e.g. using accessibility software, wearing AirPods and have notifications read out to them by Siri, or have their phone integrated with CarPlay etc, the message they'll hear is very different from what you actually intended to say.
- XMPPwocky 2y ago
  And for me on Firefox on Android, it renders as a blank space!
  - vitaminCPP 2y ago
    Same
  - amadeuspagel 2y ago
    HN filters emojis.
- xigoi 2y ago
  The irony of assuming someone’s gender for political correctness…
maxerickson 2y ago
It's not like words have unambiguous meanings, it's not a new problem.
derefr 2y ago
Unicode is descriptive, not prescriptive. The point of any glyph at all being allocated a Unicode codepoint, is that the glyph already exists in documents somewhere (either real paper documents, or digital documents in some other legacy encoding); and if Unicode didn't include a codepoint to encode that glyph, then that text wouldn't be able to be faithfully represented in Unicode. Which means that some ephemeral undocumented proprietary encoding might be used instead (as in “cellphone novels” in late-90s Japan, now permanently committed to the Internet in the form of SJIS encoding + some particular feature-phone’s SJIS pictograph codepage that no modern OS can decode.) Or worse, that the character and its contribution to the meaning of the document might be lost entirely (as in MSN or ICQ messenger emoticons, where exporting chat logs as HTML would just strip the emoticons out.) Putting whatever glyphs already exist into Unicode, no matter how rarely, is precisely what makes Unicode uni-code — i.e. an encoding that guarantees lossless archival "transmission into the future" of all texts, such that all texts should be better off transcoded into Unicode. (At least if the intent is to archive their semantic meaning as text, rather than their bytewise representation as data for software-archaeology purposes.) --- The standard of "if it already has usage, then it must get a Unicode codepoint so that the document can be Unicode-encoded" is all well and good at face value, and worked well as a guideline for the first ~10 versions of the Unicode spec. Until ~2009, pretty much nobody was arguing against codepoint allocations being "warranted." But then the modern mobile platforms realized that they essentially had a gun they could hold to Unicode’s head — in the sense that any glyph they wanted to invent, they could threaten to release into the wild as proprietary encoding if Unicode doesn’t include it. And because millions of people would be guaranteed to make tweets et al using that new symbol, Unicode is essentially forced to include it. Even though it doesn’t exist yet until that moment. All the “dumb” emoji—and color emoji in general, and the explosion in variation selectors—came after that. In est, they’re Apple and Google’s fault, not the Unicode Consortium’s.
- qsort 2y ago
  Unicode is definitely a prescriptive standard. Code point 65 is a capital A because Unicode says so -- any such standard is necessarily prescriptive. > Which means that some ephemeral undocumented proprietary encoding might be used instead I'm not arguing against the need of some standard for representing those, I'm just objecting to the technical decision of incorporating them as code points, because they don't serve the same semantical purpose. Instead you could have introduced -- for example -- a simple vector graphics format.

by qsort 2y ago

kremi 2y ago

I’m pretty sure the thumbs up emoji or the slightly smiling emoji won’t get different interpretations based on font. And here the issue is not in font differences (or different pictures of the same thing getting different interpretations): it’s the thing represented that’s actually different.

jorvi 2y ago
In the earlier days of emojis, some Samsung or blob emojis definitely look different enough from Apple emojis that it caused confusion..

sangnoir 2y ago

> A capital "A" is the same in any font; I can write a message in monospace and my interlocutor can read it in sans-serif, or tap in morse code and have it rendered in hand- writing, in all cases the difference is immaterial Many typefaces are have problematic I/l/1 and O/0 characters, and that is material enough that applications avoid those characters entirely to avoid potential confusion. The problem is deeper than unicode: the fact that any codepoints can be rendered differently from client to client or typeface-to-typeface was always problematic, even back it was mostly ASCII.

ploxiln 2y ago

Even more, fonts having multiple colors in a glyph was a huge complexity explosion for font rendering, for terminals, and more. You can see a very quick technical summary of different ways of encoding colors in fonts here: https://en.wikipedia.org/wiki/OpenType#Color_fonts https://en.wikipedia.org/wiki/OpenType#Color_fonts But anyway, images should have remained separate things, png or whatever. Fonts rendering is complex enough with complex scripts e.g. Arabic, but that is the domain of fonts/shaping/rendering. Such a hugely expensive technical mess because people want their stupid color emojis.

philistine 2y ago
You want to stay stuck in the past, that's your call. I for one stay fascinated by the prospect of colour being introduced into written languages to denote intent now that we don't have to grapple with ink. We're talking on the scale of centuries, but even Arrival didn't have the guts to include colour into the lexicon of its alien language. With, of course, accessibility for those needing it.
- deleted 2y ago
  [deleted]
- yencabulator 2y ago
  You can use colors in your document or email without needing it to be in a font.

miki123211 2y ago

Even worse, the Emoji descriptions (on some platforms) don't correspond at all to what the emoji actually represents. For example, the " " emoji, described by Unicode as "health worker" is called "non-binary doctor" by Apple. If you send that emoji in a text to somebody, and they're e.g. using accessibility software, wearing AirPods and have notifications read out to them by Siri, or have their phone integrated with CarPlay etc, the message they'll hear is very different from what you actually intended to say.

XMPPwocky 2y ago
And for me on Firefox on Android, it renders as a blank space!
- vitaminCPP 2y ago
  Same
- amadeuspagel 2y ago
  HN filters emojis.
xigoi 2y ago
The irony of assuming someone’s gender for political correctness…

maxerickson 2y ago

It's not like words have unambiguous meanings, it's not a new problem.

derefr 2y ago

Unicode is descriptive, not prescriptive. The point of any glyph at all being allocated a Unicode codepoint, is that the glyph already exists in documents somewhere (either real paper documents, or digital documents in some other legacy encoding); and if Unicode didn't include a codepoint to encode that glyph, then that text wouldn't be able to be faithfully represented in Unicode. Which means that some ephemeral undocumented proprietary encoding might be used instead (as in “cellphone novels” in late-90s Japan, now permanently committed to the Internet in the form of SJIS encoding + some particular feature-phone’s SJIS pictograph codepage that no modern OS can decode.) Or worse, that the character and its contribution to the meaning of the document might be lost entirely (as in MSN or ICQ messenger emoticons, where exporting chat logs as HTML would just strip the emoticons out.) Putting whatever glyphs already exist into Unicode, no matter how rarely, is precisely what makes Unicode uni-code — i.e. an encoding that guarantees lossless archival "transmission into the future" of all texts, such that all texts should be better off transcoded into Unicode. (At least if the intent is to archive their semantic meaning as text, rather than their bytewise representation as data for software-archaeology purposes.) --- The standard of "if it already has usage, then it must get a Unicode codepoint so that the document can be Unicode-encoded" is all well and good at face value, and worked well as a guideline for the first ~10 versions of the Unicode spec. Until ~2009, pretty much nobody was arguing against codepoint allocations being "warranted." But then the modern mobile platforms realized that they essentially had a gun they could hold to Unicode’s head — in the sense that any glyph they wanted to invent, they could threaten to release into the wild as proprietary encoding if Unicode doesn’t include it. And because millions of people would be guaranteed to make tweets et al using that new symbol, Unicode is essentially forced to include it. Even though it doesn’t exist yet until that moment. All the “dumb” emoji—and color emoji in general, and the explosion in variation selectors—came after that. In est, they’re Apple and Google’s fault, not the Unicode Consortium’s.

qsort 2y ago
Unicode is definitely a prescriptive standard. Code point 65 is a capital A because Unicode says so -- any such standard is necessarily prescriptive. > Which means that some ephemeral undocumented proprietary encoding might be used instead I'm not arguing against the need of some standard for representing those, I'm just objecting to the technical decision of incorporating them as code points, because they don't serve the same semantical purpose. Instead you could have introduced -- for example -- a simple vector graphics format.