Re: Unicode Emoji 5.0 characters now final

Ken Whistler wrote:
> *But*, the ones who do have flags on their
> phones don't want to be in the situation where the iPhone has a flag of
> Scotland which then shows up as a flag tofu on an Android phone, but an
> Android phone has a flag of Texas which then shows up as a flag tofu on
> on iPhone, etc., etc. That way leads to customer complaint madness, with
> 1000's (hundreds of 1000's?) of complaints: "My phone is screwed up, fix
> it!"

And this is where the problem becomes even worse. Because there are no
“flag tofus” for 3166-2 regions. Unlike Regional Indicator Sequences, the
fallback for all unsupported tag sequences looks exactly the same and
carries absolutely no meaning unless put through some Unicode analyzer
machine: 🏴 WAVING BLACK FLAG, a well-supported emoji that means nothing in
the context it is used in, followed by a single, featureless tofu. At least
a text containing ten different unsupported RI sequences will show you ten
distinct images, even if you are completely unaware that those peculiar
pairs of colourful letters you’ve just been sent are used to build flag
emoji.

Heck, if your device has a default font that includes CANCEL TAG (like my
phone does, but my laptop doesn’t) and therefore doesn’t render it, then
you won’t even be able to see the difference between a regular, generic
black flag and an emoji that was meant to represent some region. This could
potentially lead to great misunderstandings since a plane black flag is
often associated with anarchism and piracy, but rather rarely with England,
Scotland or Wales. The waving white flag that was used as the base in
earlier drafts at the very least had the benefit of looking like a “blank
slate” of sorts.

This is one of the few cases where the terrible web browser of the Nintendo
3DS can actually be considered superior to any modern device because for
some bizarre reason it applies modulo 65,536 to all code points on display,
resulting in tag characters rendering as visible ASCII.

It would have been much more sensible to construct subdivision flags out of
new, visible characters just like RI sequences. That way we could have had
a fallback rendering that is actually in any way useful. We could also have
preserved the original properties of the tag characters. Last time I
checked their correct usage for language tagging is still rigorously
explained in the standard despite deprecation.

But no, we absolutely had to put out this update as soon as possible
because peoplez want da emojiz. We had to use existing characters for
region sequences because if we had actually given ourselves enough time to
properly think this whole endeavour through we couldn't have made the
precious Scottish flag available until Unicode 11. (Although that hardly
seems to matter anyways seeing how we apparently now release technical
reports and data files that rely on certain characters before those
characters even exist in the standard.) And we had to use the invisible tag
characters from Plane 14 because potatoes, I guess.

You know, back when Emoji Modifiers were released I was initially sceptical
of them being spacing, visibly rendering pictographs rather than formatting
characters. Nowadays I understand that decision. Too bad we were seemingly
unable to make the same decision for flags. I eagerly await the return of
hair colour tags in Emoji 6.
Received on Wed Mar 29 2017 - 17:52:21 CDT