Re: [WhatsApp Support] Your Request: Windows Phone Client 2.10.523(ticket #7044796)

From: Philippe Verdy <>
Date: Mon, 5 Aug 2013 13:06:23 +0200

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
2013/8/5 Christopher Fynn <>
> 🇮🇳
Received on Mon Aug 05 2013 - 06:11:27 CDT

This archive was generated by hypermail 2.2.0 : Mon Aug 05 2013 - 06:11:28 CDT