Hacker News Reader

Comment by plainOldText | Hacker News Reader

Also:

  > A new "people holding hands" emoji will let users mix and match 
  > different skin tones and genders, with 171 possible combinations.[1]

This reminds me of the article "Code Inflation". [2]

[1] https://www.npr.org/2019/02/07/692260599/interracial-couples...

[2] https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=7057573

View on HN

"Code inflation" talks about programs expanding even when they already can do everything needed (e.g. true going from empty to 8k bytes). That's not the case here. These combinations didn't exist before, so the functionality is expanded, not just the code size.

The true program in the article was merely an example to illustrate one particular instance of code inflation. Unless it is some incredibly simple program like true/false, most code is always designed to be evolved and to acquire new functionality over time. The key is to know when to stop, and add functionality in a sensical fashion. I would argue most of the new emoji combinations supplied will rarely, if ever be used, so just because one can add them, doesn't mean they should.

I love emoji but they aren't needed for anything. You can always discuss periods using ordinary words.

I have to admit that whilst emoji are fun the apparently endless growth in them combined with the way they break essentially every assumed invariant about text and thus create explosions of bugs all over previously working software is ... a bit concerning.

At this point, why not just define a set of code points that let you embed an SVG into the character stream? It'd result in fewer cases of broken text where new emoji are rendered by apps that are all of six months out of date. Actually defining an endless series of semantic code points just seems like a dead end for the Unicode Consortium that opens it up to relentless attacks by activists and political nonsense because it's changed its mandate from encoding languages to defining new ones.

> embed an SVG into the character stream

I really think that we should've gone this direction as soon as it became clear people would never be satisfied with any finite set of emoji. SVG might be a bit verbose for transmission over SMS, so there's room for figuring out some simplified and more compact encoding, but this would've prevented the almost all the problems we're having with emojis today.

Multiple modifiers on one glyph? How do you implement that in a font? Or are they all separate glyphs? Overlapping characters? Strange kerning? Negative-width non-breaking space? Reverse direction for one hand?

Gender modifiers and skin tone modifiers already exist.

The two person holding hands emoji is actually implemented as person (with modifiers) + zero with joiner + handshake + zero width joiner + person (with modifiers)

Which is great, because it's backwards compatible, showing up as 3 emojis unless the font has special handling.

I’m just disappointed that they haven’t yet implemented eye and hair color options...

Reply on news.ycombinator.com