Re: Adding RAINBOW FLAG to Unicode

With extensible self-delimited regional indicator sequences the
carriers will be able to come to an agreement and to petition Unicode
to register them as named character sequences symbolizing flags not
encoded by an ISO entity, like various rainbow flags, making sure that
the format of such sequences is guaranteed not to clash with any
existing ISO 3166 format.

Also, ISO 3166-2 can have 2 or 3 letters after the dash; it makes
sense to have the letters after the dash self-delimited, if/when
REGIONAL INDICATOR DASH is added to facilitate encoding of ISO 3166-2
codes.

Leo

On Thu, Jul 2, 2015 at 10:55 AM, Mark Davis ☕️ <mark_at_macchiato.com> wrote:
> 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
>
> — 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 - 13:11:41 CDT