From: verdy_p (verdy_p@wanadoo.fr)
Date: Fri Jul 30 2010 - 05:23:11 CDT
> De : "Michael Everson"
> I like the video clip there. "Encoding in Indian standards will take about six months. Encoding in the Unicode and
IEC standards will take about 18 months to two years."
>
> Sounds as though our Government of India colleagues gave them good advice.
>
> Michael Everson * http://www.evertype.com/
Yes, and during that time, we'll get correct input from India, when it will have defined its implementation laws,
and defined its national standard.
The only emergency will come when using the symbol will be mandatory for residents in India (but this won't happen
before India clearly defines its standard, and probably not before a transition period), or for software makers
selling products in India.
India will first need to realize that adapting the ISCII standard will be tricky (there is no more any common byte
value available in its various 8-bit subtables, even if all of them have empty positions, so the basic one-to-one
transliteration schemes assuming the same position for "equivalent" letters, digits or punctuation will not work,
unless India abandons the positions reserved for C1 controls in the 8-bit version, abandonning also the 7-bit
version of ISCII, to free the positions 0xA0 and 0xFF).
Only one position in ISCII allows interoperable extension across the various ISCII tables (the "EXT" code which was
reserved for Vedic extensions, but Unicode and ISO/10646 encoded them directly in each script by overloading the
unused positions of the basic ISCII 1991 layout). But seriously, ISCII is dying... it never reached an international
standard like ISO 8859 (it could have been, as its layout was compatible with it), and most softwares are ignoring
it (possibly not in India though, and its market size is large enough that ISCII could survive or could be revived
for longer time than we think).
And there will be a need for a keyboard layout assignment (possibly replacing the old assignment for the "Rs" key if
it exists, suggesting AltGr+R for the symbol, and modifying keyboard drivers so that they will return the new code
point (if they are based on Unicode, otherwise return the ISCII bytes sequence).
This does not mean that we must not prepare the field, even if for now fonts can just encode the symbol in a PUA, or
if various systems won't accept the proposed standard code point assignment. There's no need to allocate the symbol
in the Devanagari block, because it will be shared by all the Indian scripts and many others, this will be a generic
currency symbol for all scripts.
But the proposed U+20B9 location will be perfect, independantly of the allowed glyph variations for the
representative glyph (India can vote at UTC and WG2 for the rpresentative glyph, its voice will be heard), it will
have no impact on variations occuring on fonts used outside India
In fact it does not matter if it is not formally approved for the coming Unicode 6.0 (if it's too late for the WG2
Agenda ?) as long as there's a commitment to not encode enything else at this location (now or in the future), until
India terminates its own legislation and formally requests this character
India won't need to do that if the symbol will ONLY be used on official Indian banknotes or on LEGALLY APPROVED
check forms emitted by Indian banks, or on government emissions like postal and fiscal stamps, or fiscal billings,
and if there's no plan to force customers and sellers to display the symbol for pricing and advertizing.
And internationally, India cannot force the use of the symbol, even if it's encoded, because other countries are
already using the "INR" code in their interchange.
India can still choose to retain its exclusive copyright on the symbol and protect it so that it will have a
mandatory glyph form and metrics according to governmental decisions (authorization required for using it, so fonts
including it would be illegal as they would be illegally derived works based on copyrighted work, and there will be
NO place for it in the UCS where it should then be rejected).
This archive was generated by hypermail 2.1.5 : Fri Jul 30 2010 - 05:27:38 CDT