From: verdy_p (firstname.lastname@example.org)
Date: Wed Jan 14 2009 - 05:35:07 CST
"Ruszlan Gaszanov" wrote:
> verdy_p wrote:
> >However such rendering will be difficult at small font sizes where only >white/black and a single grey pattern
would be distinctable (this will be a >severe problems for allowing the distinctions between the common tricolor
>flags if they are rendered with a single ink).
> Furthermore, monochrome rendering of flags could cause outright identity substitution in some cases. Consider for
instance monochrome glyphs of Dutch, Luxembourg, Hungarian or some other color-white-color style horizontal
tricolor flag printed in red ink. What do we get? Austrian flag.
You are trying to paraphrase what I said. However you seem to ignore the existence of the conventional patterns
used in heraldic for representing colors in monochromatic displays. Each heraldic color has its own distinctive
monochromatic pattern (hatches, crosses, dotted, tiles...) which avoids the confusion independantly of the actual
ink color used to render the patttern.
> Unless we are willing to accept polychromatic aspect as fundamental part of plain text character identity, I
really think flags should be explicitly banned from Unicode. And even if we are willing to accept such a thing, I
*still* believe flags should be explicitly banned from Unicode because of political repercussions. This is a much
bigger can of worms then corporate logos.
I have also said this argument, but the main opposition is not about colors (in fact, nothing forbids a font or
renderer to give the actual colors for a encoded character, as long as it is effectively significant for the
encoded item. Generally, plain text is independant of the color which is not encoded and stylable separately, but
Unicode does not mandate any color, and so cannot exclude multicolor characters. As long as there's no confusion
with the represented object, the rendering is valid.
The main opposition is legal and political, and also the fact that there can be a lot of flags, and that encoding
only the national flags for countries or dependencies that have ISO 3166-1 alpha-2 codes would not be enough.
In addition, trying to preallocate characters for codes that have still not been allocated in ISO 3166-1 is both a
waste of space, and not enough when looking at the Unicode stability rules (and that's why I don't want ISO 3166-1
codes which are not stable for the long term, many of them have changed or have been removed or have been
reassigned to other countries since the first release of Unicode or ISO 10646, and even with the new ISO 3166-1
policy, there is no warranty that deprecated/obsoleted codes will not be removed from the standard and never
reallocated later, because the removed alpha-2 codes are replaced by alpha-4 codes which are also unpredictable).
In addition the ISO 3166-1 collection is largely incomplete, as it contains codes for some territories and the
flags themselves may actually not be different between two regions covered by distinct ISO 3166-1 codes, and as
there are still a lot of missing dependencies (why would some dependency get their own flags encoded and not
others?), and as there are also other codes reserved for things unrelated to regions (such as trademark/IP
management organizations), or codes exceptionally reserved for international organizations (the EU for example) but
not many of them (starting by the UNO, or other wellknown ones like the ICS or NATO or Francophonie).
If national flags start being acceptable as plain text characters, I can't see any rationale that would exclude the
official flags for subnational regions as well (such as the regions encoded in ISO 3166-2). Then you'll have the
problem for encoding subnational regions in countries where the ISO 3166-2 encoding is still not defined.
You'll have problems with assigning distinct codes for regions that are not universally recognized at UN, and this
will be a problem (such as the Kosovo, or Palestinian Authority or Taiwan even if these last two have a ISO 3166-1
code). Some regions/countries are theoretically recognized, but effectively have no state administrating them; some
regions have disputed administrations (the Kosovo adminsitration is claimed by three entities: (1) the self-
proclaimed Republic of Kosovo, that has been recognized by more than 50 countries but not enough to be recognized
at UN, with a veto from some permanent members of the UN Security Council; (2) the United Nation that still has a
mandate over the region; (3) Serbia that still claims the region and is supported by some Security Council members)
Really the problem is not much that of the color (there are alternate ways to represent it if multicolor rendering
is not possible, and the fact that traditional fonts are monochromatic and apply color as a style is not a problem
of Unicode itself, but of the renderer that should not apply its own styling color instead of a significant plain
color): the actual graphic can be substitured by an empty flag showing an identifier of the flag.
The problem is also not in the number of characters needed to represent it, or in the fact that the representation
may display several characters, creating a variable width and unbreakable item. After all, you can look at complex
scripts, and the concept of abstract characters is independant of the actual graphemes or grapheme clusters used to
render them, because these characters are abstract and normally do not carry a visual characteristic, but a
The exception being the already encoded compatibility characters where a part of the semantic is carried by
rendering style distinctions like bold, italic, serif/sans-serif/monospace, superscript/subscript, narrow/wide,
meaning that the rendererer is already instructed by those characters to NOT apply its own styles to override the
style intended by their semantic in a way that would create a confusion... that's another argument that says that
some style information is already part of the encoding of some characters, and this would not be much different for
the color used to render flags (if your renderer use another color or drops some distinctions, it will be as much
destructive as using a compatibility mapping on compatibility characters or on mathematical symbols...
This problem is not specific to Unicode, and can exist as well when cnoverting from Unicode to other legacy
encodings with such remappings, or when using alternate characters to represent codes that don't have matching
glyphs in the currently availab le set of fonts, and wil be similar to the loss of information that you can also
get when you loose the distinctive colors of a graphic when faxing or photocopying an existing printed document, or
printing it onto a monochromatic printer, even in absence of any numeric source.
However, there does exist solutions to preserve the distinctions: stroke styles can be modified, color filling can
be replaced by patterns. Remember that colors are conventional, but flag colors have an historic definition in
heraldic with wellknown alternative representations (look into many heraldic books, or in documents used by
designers, or in pieces of art that are representing flags or other heraldic symbols on engraved material like the
metal of coins, or on wood or stone). The same has been used by Archeologists for representing the distinctive
color of some hieroglyphs (such as an thick bar on top or below the character or annotation diacritics).
A simple alternative distinction the represents the flag without loosing information is to show an empty flag with
its name or identifier in the middle. The distinctive heraldic colors are (partly) mandatory only when multiple
plain colors are available (such as no tinted pieces of clothes). Some flags are codified with very precise colors
only to indicate the best colors that should be used in high quality official flags to display on official poles.
But you can go in every cuontry, and you'll see that these exact theoretical Pantone colors are not respected, even
by the administrations under the authority of the law that defined these distinctive colors (as long as they are
distinctive enough to avoid all confusions with other similar national or regional entities, there's no problem).
This archive was generated by hypermail 2.1.5 : Wed Jan 14 2009 - 05:41:05 CST