Re: Flag tags (was: Re: Unicode 6.2 to Support the Turkish Lira Sign)

From: Philippe Verdy <>
Date: Thu, 31 May 2012 09:22:44 +0200

2012/5/31 Doug Ewell <>:
> A seemingly straightforward solution to the “unambiguous mapping” problem
> would be to use the existing Plane 14 tag letters along with a new FLAG TAG,
> say at U+E0002. Then <E0002, E0043, E0048> would unequivocally denote the
> current Swiss flag. No need for separate lead and trail. Simple.
> ... What’s that? Oh, sorry, never mind. Deprecated.

Not necessaryly: you could very well have sets of characters with
unambigous glyphs showing the ASCII capital letter martly enclosed:
- in a first set, it encloses the letter on the left/top/bottom sides
with the strokes that start displaying the flag (this glyph could also
include the pole)
- in a second set, it encloses the letter only on the top/bottom sides
- in the third set, it encloses the letter only on the top/bottom/right sides.

Let's not forget that even if countries do not change, and keep their
ISO 3166-1 code, their flag may change over time. So a flag encoded
with such characters should contain a year of their first official use
: this would require mapping in the second set the colon ":" and
digits for specifying the year, and mapping in the last set the digits
as well. The colon and digits are "a priori" not needed in the first

So to represent the flag of Japan, you could encode:


But if you want to use explicitly the post-1945 flag (and not the
imperial flag with sun rays), you would encode:


Which would render mostly like this, if there's no ligature defined
(several lines used here to approximate the glyphs) :

  | J P : 1 9 4 6 >

Here again, a font-defined ligature (if available) could remap it to
the actual flag.

A font can then eaqily be made, with the only constraint that the
glyphs in them should join theses enclosures. If needed, those fonts
can then create ligatures for wellknown flags, showing their apparent
goemetry. The pole could be also removed, and colors added if
supported by the font technology, or replaced by hatches in a basic
monochromatic font technology.

All these would remain standard symbols (they are superficially
"letter-like" except that the standard can say that the letters shown
in the enclosing glyphs are only used as a default fallback, but
ligatures can SAFELY replace them by the actual flag, including with
its true colors. The renderer can use the color capavilities of fonts,
if the font format supports it, or a set of icons (e.g. encoded in a
zipped archive containing SVG files an a small maping files
identifying the flag codes with the name of a SVG file, or within a
single SVG file, containing this mapping internally and mapping this
code to an internal XML anchor ID's using standard XML href's)

Note that OpenType currently does not contain any standard allowing to
map true colors used in glyphs, but there's nothing in OpenType that
prevents a font to expose several glyph variants for mapping the same
characters (or their defined ligatures) : a monochromatic version like
today, and with a new OpenType feature, a colorful version, with an
extra table found in the font that exposes the color mapping either
into an sRGBA color, or to a hatched filling pattern exposed as well
by the font as a rectangle glyph with metrics (and possibly an angle
relative to the baseline).

I am still surprised to see that OpenType still does not include such
standard. Note that hatching patterns will be defined using the
em-square of glyphs assigned to characters and ligatures, so they will
scale the same way, and would be frid-fitted and hinted the same way.
A separate definition of patterns would simplify the design of colored
fonts, as the same glyph geometries would be used. But there could
also be a separate monochromatic glyph to be defined as well in the
same font, in such a way that the glyph is defined with the pattern
integrated to its geometry.

And that CSS for example could specify a way to indicate that the
rendered characters should not use an sRGBA color (with the hatching
pattern defined in the font) but the "natural" colors defined by the
glyphs themselves: this would require only a new value for "color:
natural". If the font does not define any "natural" color for its
mapped glyphs, or the glyphs do not map any hatching patterns, then
this CSS value would be interpreted as if it was "color:inherit". An
extended version could be also "color: natural #rrggbb" : the #rrggbb
would still allow to specify the color to use if there's no natural
color in the font, or if the colors defined in the font (those that
are marked as being "important") are incompatible or not easily
distinguished with the current background (according to user's
preferences), or not accessible to the user (also according to his
preferences) : in which case the renderer would use the hatching
patterns mapped in the color map of the font, with the patterns
defined in that font.

Note that for some scripts, the "natural" color is part of their
intrinsic semantic, and there's a convention in those scripts on how
to represent color if color is not physically available (this could be
hatch patterns, or an extra stroke or bar above or below, or and
enclosing box, or an extra diacritic).

In heraldry, colors (for "metals" and "furs") are mapped to wellknown
conventional patterns, and these are also used for flags based on
heraldic designs (this works as long as you don't put furs on furs,
and you don't put metas on metals, and the colors chosen in the flag
are distinctable when mapped to heraldic colors; but many country
flags do not respect the heraldic rules, and use very precise colors
without which flags of distinct territories could be confused).
Received on Thu May 31 2012 - 02:25:44 CDT

This archive was generated by hypermail 2.2.0 : Thu May 31 2012 - 02:25:45 CDT