Indian new rupee sign
see http://timesofindia.indiatimes.com/biz/india-business/Cabinet-approves-new-rupee-symbol/articleshow/6171234.cms http://timesofindia.indiatimes.com/biz/india-business/Cabinet-approves-new-rupee-symbol/articleshow/6171234.cms http://en.wikipedia.org/wiki/Indian_rupee_sign Chinese wikipedia: http://zh.wikipedia.org/ My blog: http://shizhao.org twitter: https://twitter.com/shizhao [[zh:User:Shizhao]]
Re: Why not just change the glyph of 20A8 RUPEE SIGN?
Actually, while it's quite probable that the sign won't be used by any other currency, I believe there would be no way to prevent that. Cf. the usage of $ all over the world. I believe, other nations using a rupee _could_ adopt it. Having all that said, I don't believe though, as all recent movements of changing currency symbols aim at establishing a unique identity. Adopting a foreign country's sign would not fulfill this goal. /Sz On Thu, Jul 29, 2010 at 4:42 PM, Shriramana Sharma samj...@gmail.comwrote: Thanks all for responding. Of course it was my mistake to forget that there are other countries using the Rupee currency. Maybe the new character will be named the INDIAN RUPEE SIGN to underline the fact that this sign is only for India.
Re: Indian new rupee sign
On 30 Jul 2010, at 08:54, shi zhao wrote: see http://timesofindia.indiatimes.com/biz/india-business/Cabinet-approves-new-rupee-symbol/articleshow/6171234.cms 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/
Re: Indian new rupee sign
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).
Re: Indian new rupee sign
I find it strange that for a new currency symbol that is to come into use in six months that, in the twenty-first century, with all the modern communication methods available, that encoding in Unicode will take longer than six months. Is there any good reason why people cannot arrange that the new symbol is fully encoded into Unicode and ISO 10646 by 31 December 2010, that is, before the end of the present decade, ready to use in the next decade? If there is progress over getting the encoding done, then maybe other people will join in the effort and update fonts and whatever else needs updating by the same date. William Overington 30 July 2010
Re: Indian new rupee sign
On 7/30/10, verdy_p verd...@wanadoo.fr wrote: 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). With great difficulty we have managed to bury ISCII or at least make it irrelevant. Please see Preparation of Papers in a Two Column Model Paper Format DIT, Government of India, “Notification for Unicode 5.1.0 and its future versions as the standards for eGovernance Applications”, No. 2(32)/2009-EG-II, http://eGovStandards.gov.in http://egovstandards.gov.in/, accessed in Apr, 2010 Kindly do not resurrect it. Vinod Kumar -- पृथिवी सस्यशालिनी the earth be green
RE: Indian new rupee sign
Why does one require implementation laws to define a code point in Unicode for a new currency symbol? And what does it have to do with ISCII or keyboard layouts or usage or non-usage by people within India or abroad? One cannot make too many assumptions regarding usage. For example, Microsoft enforces the use if the Israeli currency symbol ₪ - by means of introducing it as a spelling correction for the common abbreviation שח. In normal text many, including myself, do not want this but fortunately the solution was straightforward. Jony -Original Message- From: unicode-bou...@unicode.org [mailto:unicode-bou...@unicode.org] On Behalf Of verdy_p Sent: Friday, July 30, 2010 1:23 PM To: Michael Everson; shi zhao Cc: unicode@unicode.org Subject: Re: Indian new rupee sign 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
Re: Indian new rupee sign
On 30 Jul 2010, at 12:02, Vinod Kumar wrote: With great difficulty we have managed to bury ISCII or at least make it irrelevant. Kindly do not resurrect it. Amen to that. Michael Everson * http://www.evertype.com/
Re: UTS#10 (collation) : French backwards level 2, and word-breakers.
Le jeudi 29 juillet 2010 à 15:52 -0700, Kenneth Whistler a écrit : Instead of continuing the discussion with a back and forth in email, I decided instead to write a Unicode Technical Note on the general topic, including a case study of alternative orderings for a French topic list. Those who are interested in collation and in the particular issues that were discussed in this thread may wish to take a look: http://www.unicode.org/notes/tn34/ Thanks for this interesting document. Why did you chose the fleur words ? The question discussed about the accent do not seem to arise here. The area around modèle and modelé (from model to modène), for example, seems more intersting to me. Of course, I know it's easy for me to say that without doing any work ! -- Frédéric Grosshans Chargé de Recherche Laboratoire de Photonique Quantique et Moléculaire ENS Cachan / CNRS UMR 8437 tel: (+33)1 47 40 77 15 GSM: (+33)6 09 24 29 64 e-mail: frederic.grossh...@ens-cachan.fr
RE: Indian new rupee sign
Jonathan Rosenne j...@qsm.co.il Why does one require implementation laws to define a code point in Unicode for a new currency symbol? And what does it have to do with ISCII or keyboard layouts or usage or non-usage by people within India or abroad? The national law (or an explicit licencing published by the goverment) would NOT be about the code point assignement in Unicode (this encoding space is not owned by the Indian government) or its encoding in ISCII, but only about the usage of the adopted glyph : - to open it for use by the general public, - or to make it mandatory for some usages (transactions, official fiscal forms, payment checks, price display in India), - or to liberalize its use in the rest of the world (giving an explicit licencing for some usages, but possibly explicitly stating that it should not legally refer to any other currency without prior authorization by the Indian government or its body that still owns the copyright on it). Yes, there's concern about the copyright of the symbol, which also applies to derived works (including the representative glyph currently proposed for encoding and for display in the Unicode charts and the ISO 10646 charts, where the representative glyph explicitly allow graphic style variations without breaking its visual identity). If this does not concern, you, then, there's no more any valid reason to block the encoding of the Windows logo, or of the Apple logo in the UCS (given that they are present in common character sets). Because for now this new glyph for the Indian Rupee is still an unlicenced proprietary logo (even if it's owned by a government here), and the same policy that blocks the Wavy Flying Windows logo or the Apple logo should apply here too. Anyway, I have no doubt that the intent of the Indian government is to open this use by the general public (notably because it seems that it does not seem to want it being used on its banknotes and coins, at least not immediately). All we have then is for now some opinions by govermental bodies and press releases, this is definitely not the same thing as an open licencing for other uses. Philippe
Re: UTS#10 (collation) : French backwards level 2, and word-breakers.
Frédéric Grosshans asked: Why did you chose the fleur words ? The question discussed about the accent do not seem to arise here. I was struck by the issues about space, hyphen (or lack thereof) and alternate spellings that could be illustrated by that stretch of topics, so used that as the example. That range also exhibited some of the concerns about parenthetical annotation strings. The points I wanted to make weren't really focussed all that much on the French reverse accent weighting per se. Indeed, there is a fair amount of evidence that the whole issue of French reverse accent weighting is somewhat of an artificial one anyway, as the treatment may vary from dictionary to dictionary and is basically irrelevant for most ordering of lists, anyway. I suspect that many French users would be utterly unable to tell a correct ordering of all the modèle, modelé words from an incorrect one, or would frankly much care in practice, as long as they could find what they were looking for in the list. --Ken
Re: Indian new rupee sign
On 7/30/2010 4:01 AM, William_J_G Overington wrote: I find it strange that for a new currency symbol that is to come into use in six months that, in the twenty-first century, with all the modern communication methods available, that encoding in Unicode will take longer than six months. William, perhaps you can read the RFC, particularly section 8. http://www.rfc-archive.org/getrfc.php?rfc=3718 That describes the ordinary process of character encoding. Rick
Re: UTS#10 (collation) : French backwards level 2, and word-breakers.
Le vendredi 30 juillet 2010 à 08:36 -0700, Kenneth Whistler a écrit : I suspect that many French users would be utterly unable to tell a correct ordering of all the modèle, modelé words from an incorrect one, or would frankly much care in practice, as long as they could find what they were looking for in the list. I agree with you on this, and I would like to see a real-life example (in wikipedia or wiktionnary for example) where it should matters. However, there is an order which is obviously incorrect for a french speaker, to the point that its sends the things to the place where they are unfindable : the binary order, currently used by Wikipedia, where aezè. For a french (or at least for me), separating e form é and è is similar (i.e. as unintuitive) as separating e and E. This is a common problem for me (I often struggle to find a file with an accent on my computer, because I tend to forget that zé), and I think an example obviously showing it would be nice. If you look at the list http://fr.wikipedia.org/w/index.php?title=Sp%C3%A9cial%3AToutes+les +pagesfrom=Modeleto=Mod%C3%A8nenamespace=0 you will see an order like : ... Modele atomique de Thomson Modele bio-psycho-social Modele christallerien Modele cognitif Modele conceptuel des traitements ... A very long interval, going through things like Modification ... Modulation Module ... Modèle atomique de Thomson Modèle binomial Modèle bio-psycho-social Modèle black-scholes Modèle booléen Modèle christallérien Modèle climatique Modèle cognitif while my intuition would bring the modèle and modele together. I guess it's the order 2.3 of your technical note (but I'm not sure). I think the order 2.2 would still keep euè, which remains strange and close to unusable. Frédéric Grosshans PS: However, I agree that the words fleur de lys, fleur-de-lys, fleur de lis are a particularly nice example to illustrate a topic on french ;-)
Re: Indian new rupee sign
On Jul 30, 2010, at 5:01 AM, William_J_G Overington wrote: Is there any good reason why people cannot arrange that the new symbol is fully encoded into Unicode and ISO 10646 by 31 December 2010, that is, before the end of the present decade, ready to use in the next decade? If there is progress over getting the encoding done, then maybe other people will join in the effort and update fonts and whatever else needs updating by the same date. Unicode is a complex standard whose structure involves code charts, data files, and various standard annexes and reports. Any change to the standard involves changes to at least some of these, if not all of them. This work is done by several individuals scattered around the world. Time is needed to make sure the changes are properly coordinated and made with due care. WG2 is governed by ISO rules. ISO is a large organization and involves national bodies from all over the globe. The ISO voting process involves several rounds in order to make sure that any objections are properly discussed and responded to. Even in the age of electronic communications, this takes time. And many of the people involved in both UTC and WG2 have substantial responsibilities in addition to character encoding work. (Some, indeed, do the character encoding work on their own time.) It's not necessarily easy for them to find the time to look everything over carefully. All of this is done at a deliberate pace because experience has taught that inasmuch as *any* change may have unintended consequences, making even a small change quickly may prove to create more problems than it solves. Note, for example, the early adopter who simply slapped support for the new rupee symbol by overlaying it on top of `. For a lot of people, that's a cool solution because it means that everything works *right* *now*. The problem is that it breaks a lot of other things that the person in question (and his supporters) obviously didn't even think of, and now they've got a pile of unintended consequences. Obviously this is an important new symbol, and I'm sure that WG2 and the UTC will make every effort to encode it as expeditiously as possible. As for exactly how long it will take, neither WG2 nor the UTC has even *met* since this hit the news. While it's exciting to have the new symbol, and while one does want to strike while the iron is hot, ten years from now it won't have made much difference whether it was encoded in 2010 or 2011--unless the job got botched through over-haste. Festina lente. = 井作恆 John H. Jenkins jenk...@apple.com
Re: UTS#10 (collation) : French backwards level 2, and word-breakers.
A few items on the UTN that I didn't notice previously, and one for UCA.A. 2.3. Topic List, Order 3 It is not just ICU; CLDR/LDML sets the default for alternates to * non-ignorable*, which means that probably most implementations of UCA will be non-ignorable. This is out-of-the-box, so those implementations can reset the default globally, or for a given locale, or for a given tailoring of a locale, to *shifted.* * * *So I'd suggest changing:* * * *First, let's consider the default settings for the UCA implementation by the International Components for Unicode library [ICU #ICU]. That library does a full UCA multi-level collation. Its default settings differ from the defaults for UCA per se, in that ICU does not default to the shifted option for weighting. *That means that the so-called variable elements (e.g., punctuation and symbols) are given primary weights, instead of being shifted to a weighting significance at the fourth level. Given the ICU default settings, the list would order as follows. * * *to* * * *First, let's consider the default settings for the UCA implementation by the International Components for Unicode library [ICU #ICU]. That library does a full UCA multi-level collation, using the LDML locale tailorings. The default settings for LDML differ from the defaults for UCA per se, in that LDML defaults to the non-ignorable option, not shifted. *Implementations can, however, reset the default globally, or for a given locale, or for a given tailoring of a locale, to *shifted. *That means that the so-called variable elements (e.g., punctuation and symbols) are given primary weights, instead of being shifted to a weighting significance at the fourth level. Given the ICU default settings for the root locale, the list would order as follows. * * * * B. I also noticed a significant typo in http://www.unicode.org/reports/tr10/proposed.html. * * *Sets alternate handling for variable weights, as described in Section 3.6.2,Variable Weighting #Variable_Weighting. Note that in [LDML #LDML ], blanked is not supported, and shifted is the default.* it should be: Sets alternate handling for variable weights, as described in *Section 3.6.2,Variable Weighting #Variable_Weighting*. Note that in [LDML #LDML ], *blanked* is not supported, and *non-ignorable* is the default. Implementations of LDML can, however, reset the default globally, or for a given locale, or for a given tailoring of a locale, to *shifted.* * * [There wouldn't be a need to contrast the default for LDML if it were the same as UCA.] Mark *— Il meglio è l’inimico del bene —* 2010/7/30 Frédéric Grosshans frederic.grossh...@m4x.org Le vendredi 30 juillet 2010 à 08:36 -0700, Kenneth Whistler a écrit : I suspect that many French users would be utterly unable to tell a correct ordering of all the modèle, modelé words from an incorrect one, or would frankly much care in practice, as long as they could find what they were looking for in the list. I agree with you on this, and I would like to see a real-life example (in wikipedia or wiktionnary for example) where it should matters. However, there is an order which is obviously incorrect for a french speaker, to the point that its sends the things to the place where they are unfindable : the binary order, currently used by Wikipedia, where aezè. For a french (or at least for me), separating e form é and è is similar (i.e. as unintuitive) as separating e and E. This is a common problem for me (I often struggle to find a file with an accent on my computer, because I tend to forget that zé), and I think an example obviously showing it would be nice. If you look at the list http://fr.wikipedia.org/w/index.php?title=Sp%C3%A9cial%3AToutes+les +pagesfrom=Modeleto=Mod%C3%A8nenamespace=0 you will see an order like : ... Modele atomique de Thomson Modele bio-psycho-social Modele christallerien Modele cognitif Modele conceptuel des traitements ... A very long interval, going through things like Modification ... Modulation Module ... Modèle atomique de Thomson Modèle binomial Modèle bio-psycho-social Modèle black-scholes Modèle booléen Modèle christallérien Modèle climatique Modèle cognitif while my intuition would bring the modèle and modele together. I guess it's the order 2.3 of your technical note (but I'm not sure). I think the order 2.2 would still keep euè, which remains strange and close to unusable. Frédéric Grosshans PS: However, I agree that the words fleur de lys, fleur-de-lys, fleur de lis are a particularly nice example to illustrate a topic on french ;-)
Most complete (free) Chinese font?
Does anybody know what the most complete, Chinese font is called? This is for Linux, but I think I can use just about any format. I know about the one called Unifont, which is possibly as ugly as one can make it :-) so I was hoping to find something a little bit nicer. The problem I have is that there are so many holes in most of the fonts, and it seems to be quite hard to judge which font is more complete. Are there any tools around that could show this - perhaps something that could tell how many glyphs are defined in a given interval?
Re: Most complete (free) Chinese font?
The Han Nom fonts cover everything through Extension B and look OK. They're TrueType. On Jul 30, 2010, at 1:41 PM, jander...@talentex.co.uk wrote: Does anybody know what the most complete, Chinese font is called? This is for Linux, but I think I can use just about any format. I know about the one called Unifont, which is possibly as ugly as one can make it :-) so I was hoping to find something a little bit nicer. The problem I have is that there are so many holes in most of the fonts, and it seems to be quite hard to judge which font is more complete. Are there any tools around that could show this - perhaps something that could tell how many glyphs are defined in a given interval? = 井作恆 John H. Jenkins jenk...@apple.com
