Re: Adding RAINBOW FLAG to Unicode

Why not add another 26 A-Z characters, call them "regional
supplementary symbols", and let carriers decide what to encode and how
to encode what they want with sequences <RIS> <RSS>* <RIS> to their
hearts' content?

Leo

On Thu, Jul 2, 2015 at 10:04 AM, Ken Whistler <kenwhistler_at_att.net> wrote:
>
> On 7/2/2015 2:01 AM, Philippe Verdy wrote:
>
>
> The frozen status of Antarctica ...
>
>
> ... will be addressed separately by global warming. But be that as it may...
>
>
> In really there's still no standard way to encode flags unambiguously and in
> a stable way. We'd like to have FOTW (Flags of the World) contributors to
> propose their own scheme. But it will not be compatible with the current RIS
> solution or the proposed extension. If ever such standard emerges, it will
> require encoding a new set of characters.
>
>
> The UTC is neither responsible for nor interested in a "standard way
> to encode flags unambiguously". I suspect one of the reasons this
> discussion is tending to derail into political topics and too much detail
> about particular flags and their stability and the stability of geopolitical
> entities they represent and yadda yadda, is that people seem ineluctably
> drawn to the misapprehension that this is all about standard encoding
> of flags.
>
> It is not.
>
> Rather, it is about a standard way to represent recognizable and
> interchangeable
> emoji (colorful little pictographs) of flags, using defined sequences of
> Unicode characters.
>
> The existing mechanism using regional indicator symbol (RIS) pairs was
> originally aimed at solving the following problems:
>
> 1. Enabling the reliable interchange of the legacy 10 flag emoji from
> Japanese
> carrier sets.
>
> 2. Enabling the completion of the encoding of emoji to cover the rest
> of the Japanese carrier sets without all progress dragging to a
> complete halt as national bodies in SC2 would argue interminably over
> a "standard way to encode flags unambiguously" in an ISO standard.
>
> 3. Dealing with the inevitable hue and cry: "China and Japan and the US got
> their flag!
> Why can't I get my country's flag??!"
>
> And it appears that the RIS mechanism succeeded spectacularly well in
> addressing all of those design goals.
>
> In the middle of last year, for example, there was a major media and
> internet campaign to "encode the flag of India". Well, the RIS mechanism
> handled the real issue there just fine -- when the new phones started
> coming out with support for display and interchange of emoji for flags
> using the RIS sequences, there was the emoji for the flag of India for
> everybody to use. Problem solved.
>
> And the problem which was solved was not the determination that
> the <1F1EE, 1F1F3> RIS sequence "IN" meant precisely the current
> national flag of India, the saffron, white and green tricolor with the
> Ashoka Chakra, and *not* any other flag of India (the flag of the
> Indian army, the flag of the Mughal Empire, the flag of British
> India, etc.). The RIS sequence "IN" was just mapped to the colorful
> little emoji glyph for the Indian flag that everybody wanted to interchange.
>
> The Unicode Standard is not a vexillology standard -- nor will it ever be.
> It is a standard for the encoding and interchange of characters.
>
> The *character* problem we are faced with here is that people want
> to use and interchange colorful little emoji pictographs of various
> flags in text streams. The RIS mechanism addresses a significant
> part of that problem, but is not extensible to cover the full scope of the
> demand.
>
> And what is the scope of the additional demand?
>
> 1. The first part can be summed up as: the flag of Scotland problem.
>
> In other words, there are a number of high visibility, high demand,
> widely recognized regional flags that would be interchanged as just
> more emoji pictographs, if a mechanism for that were available.
>
> People who want to use an emoji for the flag of Scotland just as
> easily as someone can use an emoji for the flag of Great Britain
> are not going to accept an argument that says, "Well, we can't do
> that on your phones because there is no 3166-1 country code registered, so
> we can't map a Scotland flag emoji glyph to a RIS pair."
>
> Hence the PRI #299 proposal: for an extension mechanism that would
> address the flag of Scotland problem in a generic and reasonably
> stable way.
>
> 2. The second part can be summed up as: the rainbow flag problem.
>
> In other words, there are a number of high visibility, high demand,
> widely recognized non-governmental flags that would be interchanged
> as just more emoji pictographs, if a mechanism for that were available.
>
> From the public's point of view, this is another no brainer: if the
> flag of Japan and the flag of Scotland, why not the rainbow flag??!
> They aren't interested in the limitations of the underlying representation
> mechanisms, nor should they be, IMO.
>
> The problem the UTC faces here is that there are a number of
> reasonable and popular candidates, which the rainbow flag amply
> exemplifies, for more colorful little emoji pictographs for flags that
> people would like to interchange -- but there is no obvious and
> extensible way to do so reliably in terms of sequences of Unicode
> characters in a plain text stream. The PRI #299 proposal does not
> extend into this realm, for many of the reasons pointed
> out by Doug Ewell.
>
> There are a number of potential approaches to address the rainbow
> flag problem. For example:
>
> a. use private-use characters
> b. pursue one-by-one encoding of each newly desired flag pictograph as a
> symbol
> c. extend the unicode_region_subtag and unicode_subdivision_subtag
> scheme in CLDR to add some new subtag addressing a separate,
> non-geopolitical hierarchy
> d. create a separate extension using TAG characters but with a
> syntax not dependent on CLDR subtag definitions
> e. create a registry of flag entities suitable for representation as
> emoji, together with a "c" or "d" style syntax
> f. something else?
> g. do nothing (and perhaps hope that stickers will solve the problem)
>
> If we are to make any progress here in addressing the actual scope
> of "the rainbow flag problem", I suggest we focus on the details and
> pros and cons of suggestions like those of a through g above, rather than
> pursuing more discussion recapitulating the history of the borders of Tibet
> --
> which truly are out of scope here.
>
> --Ken
>
>
Received on Thu Jul 02 2015 - 12:47:43 CDT