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 <[email protected]>: > 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? >> >> >> >
