Re: Flag tags

Note that I gave an URL for the Flags Of The World site which is
hosted by a commercial vendor of manufactured flags.
But as the site is built from a collection of static HTML webpages,
without any script, its is easily mirrored on various place.
For now, Wikipedia prefers referencing a vendor-neutral website at this address:

http://flagspot.net/flags/

The pages are identical, only the base URL change, all relative URLs
are identical starting at the "flag/" folder.

It is fed by discussions and contributors on its old mailing list (the
main place of discussions related to the FOTW project), whose volume
is huge (about than one half million messages sent since 1993, about
2000 or 3000 mails per month), notably because it also conveys photos,
and graphic designs. But the effective discussions are even larger
within the local associations that are members of FIAV.

The FIAV itself (from which the FOTW wide is just a small visible part
containing a summary of the huge collection of flags discussed and
maintained by the various member associations and its contributors)
has offices in Belgium (presidence), Texas (general secretariat), and
UK (conferences). I think it is illusory to restart completely the
huge work already performed by the FIAV and exposed partly in the FTOW
website.

If you ever want to know how best the codification should be made (how
many distinct characters you need to support the reencoding into
abstract symbols that will later be recombinable into ligatures
showing the actual flags), I suggest that the UTC contacts the general
secretary.

All contact details are on this page: http://flagspot.net/flags/vex-fiav.html

(once again ignore the base URL "http://flagspot.net" before "/flag",
which varies depending on the various website mirrors you'll find
easily on web search engines).

Immediately, you won't need anything more that a subset of symbols to
represent each letter of the code. The registry can be developped
later only for standardizing the recognized ligatures. In the Unicode
standard, there's no need to encode any subcollection of flags, even
if we can explain how to use these symbols into ligatures.

The representative glyphs shown in TUS and ISO/IEC 10646 will just
display the default symbols containing the associated ASCII letter
used in the registry (and most probably this should be restricted to
ASCII characters usable in common filesystems for naming graphic files
in whatever format the rendering applications will recognize, or to
name the glyphs of ligatures when developing fonts showing more than
just the separate representative glyphs displaying the codes). For
allowing compativility with filenames in various filesystems, I just
suggest using a single letter case, avoiding characters like "/" or
"\" which could be incompatible with some OSes or with the syntax of
hierarchial URLs.

Characters currently allowed for language codes should all be usable :
ASCII letters, digits, hyphen separators. The slash could be added
later for precise versioning purpose. The slash in a standard code
would be mapped to the symbol not showing any letter or digit, but a
space, in their representative glyph.
I'm not sure that the colon shuld be used as it may cause
compatitibility problems when deciphering a series of symbols into
therir associated ASCII character par of codes that would be rempped
to filenames. And the dot should not be used if it breaks file
extensions in local filesystems or in URLs for reeiving a known flag
from a collection of prebuilt glyphs stored as graphic files (SVG,
PNG...).

If we encode each character of the Flag code into symbols, we'll need
then less than 50 characters in each subcollection for the start
symbol, the medial symbols, and the final sybols. All would fit within
192 codepoints allocated in the SMP (or in Place 14, but that plane is
not intended for visible symbols).

As long as a policy is documented that allows starting representing
immediately at least the generic country flags with their ISO 3166
codes, in a viable namespace, using just 3 Unicode symbols, it will
remain safe for immediate use. Versioned flags may be encoded later
once the registry is working.

2012/6/1 Asmus Freytag <asmusf_at_ix.netcom.com>:
> On 5/31/2012 5:06 PM, Michael Everson wrote:
>>
>> On 1 Jun 2012, at 00:59, Doug Ewell wrote:
>>
>>> So I could propose, say, the Pigpen cipher?
>>
>> I would rather you help convince people about the Unifon proposal.
>>
> hehe.
>
> A./
>
> PS:what's Unifon and what's it got to do with it?
>>
>>
>>
>
Received on Thu May 31 2012 - 20:42:44 CDT