Re: Unicode Emoji 5.0 characters now final

From: Philippe Verdy <>
Date: Thu, 30 Mar 2017 02:16:26 +0200

2017-03-30 1:29 GMT+02:00 Richard Wordingham <>:

> On Thu, 30 Mar 2017 00:52:03 +0200
> Charlotte Buff <> wrote:
> > 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.
> I don't see why the tag characters can't be represented by some form of
> corresponding ASCII characters as a fallback registering. The
> bracketing pair U+1F3F4 WAVING BLACK FLAG .. U+E007F CANCEL TAG
> declares a sequence of 3 to 6 intervening ordinary tags to be a flag
> emoji, and in an OpenType font a GSUB contextual substitution can
> easily convert unrecognised sequences to modified ASCII characters. It
> does not have to explicitly handle each possible combination.

I also think so: the unique black flag (even if it is marked on the corner
with a ? on a diamond) is the worst solution. You can easily set up a
left-side part showing the hoist and the start of the flag, a right part
showing the floating end of the flag, and display the letters with top and
bottom borders connecting together and with the left-side and right-side
part. May be you can also arrange the letters in rows: the first top row
for the 2-letter ISO 3166-1 code, the bottom row for the appended 1-to-4
characters code (letters and digits) of the subdivision.

You may also improve the display by displaying the last letters on top of
the national flag. If subdivision codes are known you may alternatively
render a short name of the subdivision above or below the national flag
(but here there's a problem of language choice: even if official names are
accepted, some subdivisions have several official names in distinct
languages, possibly in distinct scripts; and when there's only one,
probably many users will have problems reading these labels in a foreign
script, such as Arabic or Chinese)

My opinion is that renderers should better support the interactive display
of hints in the user language of its UI, independantly of the language of
the encoded document itself, if the rendering engine is capable of such
interactivity, provided that there's no other competing hint such as title
attributes which may be used in HTML to explain the flag ven when it is
actually rendered. The same will apply for non-graphical rendering such as
aural rendering., instead of spelling the code letters (as a last fallback).

May be it will be larger than an actual flag, but I see no problem at all
if all flags do not have the same ratio (in fact ratios are already not the
same for the official flags of recognized countries). There is absolutely
no obligation
Received on Wed Mar 29 2017 - 19:17:33 CDT

This archive was generated by hypermail 2.2.0 : Wed Mar 29 2017 - 19:17:34 CDT