Re: Adding RAINBOW FLAG to Unicode

Again, that has no advantage over PUA characters. Carriers/vendors can
*already* add whatever PUA characters they want to fonts and keyboards. But
of course, the problem is interoperability; you send a flag to a friend for
your favorite vacation spot, Florida, and the friend sees a flag for New
Jersey.

Mark <https://google.com/+MarkDavis>

*— Il meglio è l’inimico del bene —*

On Thu, Jul 2, 2015 at 7:46 PM, Leo Broukhis <leob_at_mailcom.com> wrote:

> 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:57:11 CDT