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 <l...@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 <kenwhist...@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 > > > > >