The way they are encoded, they assume that they will contextually represent the start or the end of the code. This completely breaks the character model and these characters will probably never be used as such.
It would have been easier to support them if there was TWO additional bracketing characters : - 1F1E4 REGIONAL INDICATOR START # similar to '[' punctuation - 1F1E5 REGIONAL INDICATOR END # similar to ']' punctuation Then all these characters would have a reasoable default glyph assignable to them : - The 26 letters would be drawn enclosed in a box whose only the top and botem borders are visible (in the chart, the left and right borders could be dotted, with the left/start side with a small desdending hoist to suggest the meaning. - The START/left character would represent in the horizontal center the vertical hoist (and in the chart the right side would add the rest of a narrow flag with dotted lines). - The END/right character would represent in the center the floating side of the flag (and in the chartwould add the rest of a narrow flag with fotted lines. - The two-character sequence START+END would be valid and could display an empty/white flag, and could also mean the explicit absence of region indicator i.e. any place on Earth). To be complete, there should also exist an minus-hyphen separator, and the 10 decimal digits, to allow all ISO 3166 codes (not just the 2-letter ISO-3166-1 codes, but as well the longer codes assigned to historic countries), the representative glyph being similar to those for the 26 Basic latin letters. Here also the START/END are needed to allow correct delimitation of codes. This would mean a total of 13 additional codes (they would all fit in the two columns 1F1Dx-1F1Ex, the first column being used by the 10 digits and separators, the second one being containing the two START/END delimiters before the existing 26 letter; this would still leave 9 unassigned positions in these two columns (possibly for additional separators needed for some distinctions, e.g. COLON for versioning with a date). Some visual variants of the flag. Could be used on the START delimiter (to show/hide the hoist, or to represent the flah hanging vertically) and on the END delimiter (variants of the free floatting side, instead of the flat rectangular look, e.g. curved top and bottom borders, and slightly falling down, or flag attached to hoists on both sides) Standard ligature system could be used to create fully connected flags and sequence would no longer be recognized contextually (the START/END pair is expected to be present). Implementations would then be free to remap to map actual emoji icons (possibly colorful) instead of the default ligatures for the actual flags without being limited to contextual ISO 3166-1 pairs. ---- For now the representative glyphs for isolated letters (using an enclosing dotted square) are quite bad, they do not suggest any flag. In my opinion they should also display the top and bottom horizontal borders with continuous strokes, instead of dotted strokes that are used (correctly) on the left and right vertical sides). In other words, the existing characters have been defined without considering even the actual usage, and they will probably never be used in any font, and finally not in any renderer. I do think that the way they were encoded was explicitly to prevent their use (just like with language indicators in the special plane, defined only to be deprecated immediately because they are unusable...) Most applications will prefer displaying only the 4 ASCII characters "[FR]" instead of 2 letter-like regional indicator characters "FR" in this subblock, even if they can't be automtically be converted to emoji's (I wonder why this could not happen, given that Emoji applications are mostly those for interpersonal communication via SMS/MMS or chat, which frequently convert automatically sequences of ASCII characters like :-) into graphic icons) 2013/8/5 Christopher Fynn <[email protected]> > 🇮🇳 > > http://en.wikipedia.org/wiki/Regional_Indicator_Symbol > >
