Iranian Rial sign proposal
Dear friends, You can find a proposal for encoding Iranian Rial sign in Unicode at: http://developer.sharif.edu/farsiweb/proposal/rial.html We really appreciate your ideas and comments. Please send them personally to me (or to the list if it may be benefical for others). I will send it to UTC for consideration after that. --roozbeh
Re: Iranian Rial sign proposal
If they don't put it in this minute, there is something WRONG. It is a CURRENCY symbol, for Pete's sake! I mean, DOLLAR SIGN is not LATIN LETTER S WITH STROKE And it is *UNI*code Oh. You didn't tell us whether it goes to the left or to the right of the digits, did you? And it is considerably more important than KAWAII MYRIADS HEART (for counting pinball points). *** JUUICHIKETAJIN *** Roozbeh Pournader <[EMAIL PROTECTED]> wrote: > > Dear friends, > > You can find a proposal for encoding Iranian Rial > sign in Unicode at: > > http://developer.sharif.edu/farsiweb/proposal/rial.html > > We really appreciate your ideas and comments. Please > send them personally > to me (or to the list if it may be benefical for > others). I will send it > to UTC for consideration after that. > > --roozbeh > > > ___ Get your own FREE Bolt Onebox - FREE voicemail, email, and fax, all in one place - sign up at http://www.bolt.com
Re: Iranian Rial sign proposal
In a message dated 2001-04-03 16:25:22 Pacific Daylight Time, [EMAIL PROTECTED] writes: > You can find a proposal for encoding Iranian Rial sign in Unicode at: > > http://developer.sharif.edu/farsiweb/proposal/rial.html I would think you would want this symbol to be encoded in the Currency Symbols block (U+20A0 through U+20CF), not in the largely deprecated Arabic Presentation Forms-A block. -Doug Ewell Fullerton, California
Re: Iranian Rial sign proposal
Like Doug, I am a little curious as to the decision on where the symbol would go... would you really want it in the presentation forms that are merely for backwards compatibility? I think there are two options for currency symbols: 1) In the curreny Symbols block if there is even the remotest chance that this might be a shared symbol, or 2) In a true script block (not the presnentation forms) otherwise. Otherwise, I think the proposal has very good information in it. michka - Original Message - From: "Roozbeh Pournader" <[EMAIL PROTECTED]> To: "Unicode List" <[EMAIL PROTECTED]> Sent: Tuesday, April 03, 2001 4:09 PM Subject: Iranian Rial sign proposal > > Dear friends, > > You can find a proposal for encoding Iranian Rial sign in Unicode at: > > http://developer.sharif.edu/farsiweb/proposal/rial.html > > We really appreciate your ideas and comments. Please send them personally > to me (or to the list if it may be benefical for others). I will send it > to UTC for consideration after that. > > --roozbeh > > >
Re: Iranian Rial sign proposal
Robert, More and more people are of the opinion with each message that if they do not remove you from the Unicode List that there is in fact something wrong. You need to stop this sort of nonsense. NEVER has the UTC refused to look at a proposal, but do you think that somehow procedure is neglected merely because someone thinks it is an "obvious" point? This is a DISCUSSION list, and Roozbeh took it upon himself as a mature and responsible member of the list to discuss the proposal he has. His post was appropriate and I did in fact have the same concern that Doug mentioned in relation to where the symbol might be encoded. This is of course why we DISCUSS things. YOUR response (on the other hand) was incredibly immature and irresponsible, and serves for no purpose other than to remind us how wonderful it is to be an adult. Please try to post at least as many useful messages as you do irrelevant ones that do nothing but annoy others obviously a better ratio would be preferred but I think that anyone who can at least manage to have a 1:1 ratio here has a good chance of not being booted of the list for the sake of POLLUTION CONTROL. michka
Re: Iranian Rial sign proposal
Like Doug, I am a little curious as to the decision on where the symbol would go... would you really want it in the presentation forms that are merely for backwards compatibility? I think there are two options for currency symbols: 1) In the curreny Symbols block if there is even the remotest chance that this might be a shared symbol, or 2) In a true script block (not the presnentation forms) otherwise. Otherwise, I think the proposal has very good information in it. michka
Re: Iranian Rial sign proposal
11digitboy wrote: > If they don't put it in this minute, there is something > WRONG. It is a CURRENCY symbol, for Pete's sake! I > mean, DOLLAR SIGN is not LATIN LETTER S WITH STROKE > And it is *UNI*code > Currency symbols should probably be encoded without delay, but is this really a currency symbol? It appears to be the word "rial" written in Arabic. In Roozbeh Pournader's proposal, justification is given that "rial" has existed for a long time as a single keystroke on Iranian keyboards, but is this sufficient? The proposal mentions also that "rial" is typically rendered with letters which are more narrow than the norm, but might this be because of the physical limitations imposed by being fit onto one typewriter key? Precedents exist for encoding Arabic words/phrases in Unicode as single code points, see U+FDFA and U+FDFB. If "rial" is to be encoded, perhaps the Arabic Presentation Forms range would be the best place. In an older book covering Iranian coinage one can find, in addition to "rial", other monetary units like "dinar", "toman", "kran (qiran)", etc. The letters forming any of these monetary unit words might combine calligraphically to form unique and beautiful ligatures, but perhaps this should be treated as a display/fonts issue rather than an encoding issue. Best regards, James Kass.
Re: Iranian Rial sign proposal
On Tue, 3 Apr 2001, Michael (michka) Kaplan wrote: > Like Doug, I am a little curious as to the decision on where the symbol > would go... would you really want it in the presentation forms that are > merely for backwards compatibility? I think there are two options for > currency symbols: But it's only for backward compatiblity... > 1) In the curreny Symbols block if there is even the remotest chance that > this might be a shared symbol, or It won't be. It's nothing more than a rendering of word Rial, sometimes narrower to fit in one column in fixed-width fonts. It doesn't have any international use, because it may be mistaken by Saudi Arabic Rials or things like that. --roozbeh
Re: Iranian Rial sign proposal
On Wed, 4 Apr 2001 [EMAIL PROTECTED] wrote: > Oh. You didn't tell us whether it goes to the left > or to the right of the digits, did you? Is this needed in the proposal for the character itself? --roozbeh
Re: Iranian Rial sign proposal
On Tue, 3 Apr 2001 [EMAIL PROTECTED] wrote: > I would think you would want this symbol to be encoded in the Currency > Symbols block (U+20A0 through U+20CF), not in the largely deprecated Arabic > Presentation Forms-A block. No, I like it in the Arabic Presentation Forms, because it's only a ligature needed for round-trip compatiblity, it's not a real currency sign. We will discourage its use in future national standards also. --roozbeh
Re: Iranian Rial sign proposal
On Wed, 4 Apr 2001, James Kass wrote: > Currency symbols should probably be encoded without > delay, but is this really a currency symbol? It appears > to be the word "rial" written in Arabic. I agree. But we need it for round-trip compatiblity with the national character set. There is a difference between "Reh Alef Yeh Lam" and "Rial" in the users' text files, and that should be respected. > In Roozbeh Pournader's proposal, justification is given that > "rial" has existed for a long time as a single keystroke on > Iranian keyboards, but is this sufficient? My own position in HCI (national governmental body responsible for IT standards) has been against asking for encoding it. But after I found that we cannot map a key to a sequence of characters in X, that changed. And this is perhaps the only key on a standard keyboard that doesn't have a character in Unicode. > The proposal mentions also that "rial" is typically rendered with > letters which are more narrow than the norm, but might this be because > of the physical limitations imposed by being fit onto one typewriter > key? Not only typewriters, but also on price tags that the extra width was an obstacle. > Precedents exist for encoding Arabic words/phrases in > Unicode as single code points, see U+FDFA and U+FDFB. > If "rial" is to be encoded, perhaps the Arabic Presentation > Forms range would be the best place. Exactly. > In an older book covering Iranian coinage one can find, in > addition to "rial", other monetary units like "dinar", "toman", > "kran (qiran)", etc. The letters forming any of these > monetary unit words might combine calligraphically to > form unique and beautiful ligatures, but perhaps this > should be treated as a display/fonts issue rather than > an encoding issue. But no one has asked (or will ask) for them. I'll promise :) Rial is the national currency, it is in a standard character set, and it is on a standard keyboard. And we only ask for it to be encoded in a deprecated block. Too much? BTW, I found your comments really helpful... Thanks a lot. --roozbeh
RE: Iranian Rial sign proposal
Roozbeh Pournander wrote:
> You can find a proposal for encoding Iranian Rial sign in Unicode at:
> http://developer.sharif.edu/farsiweb/proposal/rial.html
I have two minor points.
First one is about the bidi category. I see that you suggest "AL" (Arabic
Letter):
Recommended Unicode character properties for the character is as
follows:
1. Character Name: ARABIC LIGATURE RIAL
2. General Category: Sc (Symbol, Currency)
4. Bidirectional Category: AL (Right-to-Left Arabic)
5. Character Decomposition Mapping: 0631 06CC 0627 0644
But all other characters in general category "Sc" (Currency Symbol) have
bidi category "ET" (European Number Terminator), so I would suggest to
avoid this exception.
This makes sense, because currency symbols are normally associated with
numbers (they normally occur before or after an amount), and bidi category
"ET" ensures the correct behavior with numbers.
I try to anticipate two objections that you could make to this:
1) "ARABIC LIGATURE RIAL will normally be used in a RTL context".
Also U+20AA (NEW SHEQEL SIGN, the Israeli currency symbol) is used in a RTL
context, but it has bidi category "ET", not "R" (RTL Letter).
2) "ARABIC LIGATURE RIAL is decomposed by four letters of bidi
category 'AL'". Also U+20A8 (RUPEE SIGN is decomposed as the two letters
U+0052 U+0073 (i.e. "Rs"), but it has bidi category "ET", not "L" (LTR
Letter).
My other point has already been mentioned by others: the Currency Symbols
block (U+20A0...) sounds like a more appropriate area.
The objection that ARABIC LIGATURE RIAL is a discouraged character for
backward compatibility is quite weak, because this is true of many (most?)
other currency symbols in that block:
U+20A0 (EURO-CURRENCY SIGN): a mistake in Unicode 1.0, retained for
compatibility.
U+20A3 (FRENCH FRANC SIGN), U+20A4 (LIRA SIGN), U+20A7 (PESETA
SIGN), U+20AF (DRACHMA SIGN): will disappear next year with euro. Moreover,
Franc and Lira are obsolete symbols ("FF" and "Lit" are now more common).
U+20A5 (MILL SIGN): which currency is so worthy to require a special
symbol for 1/1000?
And it is also true for many currency symbols in other blocks:
U+00A4 (CURRENCY SIGN): who ever used this?
U+FE69 (SMALL DOLLAR SIGN), U+FF04 (FULLWIDTH DOLLAR SIGN), U+FFE0
(FULLWIDTH CENT SIGN), U+FFE1 (FULLWIDTH POUND SIGN), U+FFE5 (FULLWIDTH YEN
SIGN), U+FFE6;FULLWIDTH WON SIGN: just there for roundtrip conversion with
CJK charsets
On the other hand, the main common feature of characters in the Arabic
Presentation Forms blocks A and B is their being "presentation forms" (i.e.
glyphs) for Arabic contextual forms and ligatures.
It is true that there are a few full words, but their are all religious
terms in special calligraphic forms, and there was no specific block for
such things.
_ Marco
Re: Iranian Rial sign proposal
Michka> You need to stop this sort of nonsense. NEVER has the UTC refused Michka> to look at a proposal, but do you think that somehow procedure is Michka> neglected merely because someone thinks it is an "obvious" point? I think you are totally over-reacting, Michael. You are reading more into Robert's words than is actually there. - Mark Leisher Times are bad. Children no longer obey Computing Research Labtheir parents, and everyone is writing New Mexico State University a book. Box 30001, Dept. 3CRL-- Marcus Tullius Cicero Las Cruces, NM 88003
Re: Iranian Rial sign proposal
James> In an older book covering Iranian coinage one can find, in addition James> to "rial", other monetary units like "dinar", "toman", "kran James> (qiran)", etc. The letters forming any of these monetary unit James> words might combine calligraphically to form unique and beautiful James> ligatures, but perhaps this should be treated as a display/fonts James> issue rather than an encoding issue. The explanation I was given was that words like "toman" are used more like "dollar" as opposed to "rial," which is used like "$" (i.e. they are "spelled out" in a sense). - Mark Leisher Times are bad. Children no longer obey Computing Research Labtheir parents, and everyone is writing New Mexico State University a book. Box 30001, Dept. 3CRL-- Marcus Tullius Cicero Las Cruces, NM 88003
RE: Iranian Rial sign proposal
Roozbeh, >It doesn't have any international use, because it may be mistaken >by Saudi Arabic Rials or things like that. I am sorry to see that much of the Arabic support has left out Farsi & Urdu support because of short sightedness. They could have planned ahead and gone the extra bit to add the support in the beginning. I think that we should look into if other countries use a different form of Rial as you do. Then we can make an informed decision. It may be that yours is a unique case or it may be that other countries to the same or similar things. If they do, then it may be best to include their input as well. I am sure that if you have a problem fitting Rials on to a price tag that the problem is not unique to Iran. Carl -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Roozbeh Pournader Sent: Wednesday, April 04, 2001 3:34 AM To: Michael (michka) Kaplan Cc: Unicode List Subject: Re: Iranian Rial sign proposal On Tue, 3 Apr 2001, Michael (michka) Kaplan wrote: > Like Doug, I am a little curious as to the decision on where the symbol > would go... would you really want it in the presentation forms that are > merely for backwards compatibility? I think there are two options for > currency symbols: But it's only for backward compatiblity... > 1) In the curreny Symbols block if there is even the remotest chance that > this might be a shared symbol, or It won't be. It's nothing more than a rendering of word Rial, sometimes narrower to fit in one column in fixed-width fonts. It doesn't have any international use, because it may be mistaken by Saudi Arabic Rials or things like that. --roozbeh
RE: Iranian Rial sign proposal
On Wed, 4 Apr 2001, Marco Cimarosti wrote: > But all other characters in general category "Sc" (Currency Symbol) have > bidi category "ET" (European Number Terminator), so I would suggest to > avoid this exception. > > This makes sense, because currency symbols are normally associated with > numbers (they normally occur before or after an amount), and bidi category > "ET" ensures the correct behavior with numbers. I noted that, but the point is that it's not a unique sign for international use. It's only a compatiblity character, and it will be used only in "legacy" Persian texts that are converted from ISIRI 3342 (which has its own bidi, with only three categories: Left-to-right, Right-to-left, and Persian Number). It is a seqence of Arabic letters regarding bidi: If it is used after a sequence of "EN"s (Persian numbers are considered to be in that category) in an RTL context, it should appear to their left, and not right. Making it "ET" will make it appear to the right. (Note that the example I'm giving is almost always the case. Almost always, the user will press the key only after a sequence of Persian digits in an RTL context.) If this exception comes to be problematic, we prefer it to be in general categort "Lo" (Letter, Other) rather than changing the bidi category to "ET". > 1) "ARABIC LIGATURE RIAL will normally be used in a RTL context". > Also U+20AA (NEW SHEQEL SIGN, the Israeli currency symbol) is used in a RTL > context, but it has bidi category "ET", not "R" (RTL Letter). I noted that about U+20AA. The difference is "will normally be used" vs "will always be used". New Sheqel as a currency sign in unambiguous, but this symbol as a currency sign in international context will be both ambigiuous and unreadable. > 2) "ARABIC LIGATURE RIAL is decomposed by four letters of bidi > category 'AL'". Also U+20A8 (RUPEE SIGN is decomposed as the two letters > U+0052 U+0073 (i.e. "Rs"), but it has bidi category "ET", not "L" (LTR > Letter). The same points work here. (BTW, the Rupee sign seems to be the only currency sign having a decomposition. It would be great to know about the history of the character...) > My other point has already been mentioned by others: the Currency Symbols > block (U+20A0...) sounds like a more appropriate area. Same points. And we want to hide it somewhere that people won't come to it and implement it. :) And we want to ask everyone to convert it to "ZWNJ Reh Farsi-Yeh Alef Lam ZWNJ" as soon as they could. Taking X keybaord, we will ask the application to do the conversion. > On the other hand, the main common feature of characters in the Arabic > Presentation Forms blocks A and B is their being "presentation forms" (i.e. > glyphs) for Arabic contextual forms and ligatures. We believe this to be something like a ligature. A currency sign for Rial never existed. It was only the word so common that people assigned a key on typewriters for it. It may also be considered a presentation form, because it's written narrower than the word Rial itself. And then it made its way into the national standard character set. And now we need it for round-trip. And we do want to discourage its use in all ways (unless unavoidable), and we want to mark it as deprecated in all ways. (...Your message went really serious, thanks. I'm really out of energy now... :) I have updated the proposal with points others made. Does anyone believe that we should write about the reasons for chosing the categories in the proposal? --roozbeh
Re: Iranian Rial sign proposal
In a message dated 2001-04-04 3:42:20 Pacific Daylight Time, [EMAIL PROTECTED] writes: > On Wed, 4 Apr 2001 [EMAIL PROTECTED] wrote: > > > Oh. You didn't tell us whether it goes to the left > > or to the right of the digits, did you? > > Is this needed in the proposal for the character itself? It would probably not be required, but might be a nice little extra piece of information. It always helps to know as much as possible about the intended use of a proposed character. -Doug Ewell Fullerton, California
Re: Iranian Rial sign proposal
On Wed, 4 Apr 2001, Mark Leisher wrote: > The explanation I was given was that words like "toman" are used more like > "dollar" as opposed to "rial," which is used like "$" (i.e. they are "spelled > out" in a sense). No. "Toman" is the unofficial name for "10 Rials". Although Rial is the official currency and is used for the national budget, for balance sheets, on bank notes, or anywhere else one may need officiality, Toman is almost used everywhere else: in conversations, on the price tags, and most important of all, in people's minds. We convert Rials to Tomans in our minds when we want to get a sense of the value. Both Rial and Toman are always spelled. The Rial sign we are proposing is not that much different from the word Rial. It's only a character in a legacy charset. About the other currencies James mentioned, "dinaar" and "gheraan", they are historic currencies. "gheraan" was the old official name for Rial more then 80 years ago. "dinaar" is 1/100th of a Rial, and when a US dollar is worth 9000 Iranian Rials here, you can simply guess why it's not used anymore, although it's still considered official. I think 50 Dinar coins went unofficial about 30 years ago. --roozbeh
Re: Iranian Rial sign proposal
On 04/04/2001 06:06:45 AM unicode-bounce wrote: >My own position in HCI (national governmental body responsible for IT >standards) has been against asking for encoding it. But after I found that >we cannot map a key to a sequence of characters in X, that changed. So, we have some broken technology. One way to fix it is to add a presentation form to Unicode. But isn't there another fix -- to build into X the ability to map a key to a sequence of characters (which surely would be useful in other situations)? Of course, adding a presentation form in Unicode is the easier thing to do. I wonder if it's the right thing to do. >But no one has asked (or will ask) for them. I'll promise :) Rial is the >national currency, it is in a standard character set, and it is on a >standard keyboard. And we only ask for it to be encoded in a deprecated >block. Too much? Given all those circumstances, maybe not. Would you propose that it have a canonical or compatibility decomposition? If so, I believe that would be problematic with respect to stability of normalization forms. - Peter --- Peter Constable Non-Roman Script Initiative, SIL International 7500 W. Camp Wisdom Rd., Dallas, TX 75236, USA Tel: +1 972 708 7485 E-mail: <[EMAIL PROTECTED]>
Re: Iranian Rial sign proposal
On 04/04/2001 09:34:25 AM unicode-bounce wrote: >Michka> You need to stop this sort of nonsense. NEVER has the UTC refused >Michka> to look at a proposal, but do you think that somehow procedure is >Michka> neglected merely because someone thinks it is an "obvious" point? > >I think you are totally over-reacting, Michael. You are reading more into >Robert's words than is actually there. I won't say that Michael didn't go overboard, but on the other hand, Robert was shouting, which generally isn't needed on this list, and I suspect it is not appreciated by many. - Peter --- Peter Constable Non-Roman Script Initiative, SIL International 7500 W. Camp Wisdom Rd., Dallas, TX 75236, USA Tel: +1 972 708 7485 E-mail: <[EMAIL PROTECTED]>
RE: Iranian Rial sign proposal
On Wed, 4 Apr 2001, Carl W. Brown wrote: > >It doesn't have any international use, because it may be mistaken > >by Saudi Arabic Rials or things like that. Oh sorry. It seems that I used the wrong phrase. By international use I meant using it in LTR contexts, after Latin numbers, etc. I was telling that it won't be used like New Sheqel. Look at the context again... > I think that we should look into if other countries use a different form of > Rial as you do. Then we can make an informed decision. It may be that > yours is a unique case or it may be that other countries to the same or > similar things. If they do, then it may be best to include their input as > well. You're right. The reason for putting the proposal public is asking for their input also. BTW, after looking at ISO 4217 list of currencies, I found that Rial is also used as a currency in Qatar, Saudi Arabia, and Yemen. Would anyone with access to people there ask for their input? (If they have it in a character set, if they have it on keyboards, if they use another visual form sometimes, etc.) > I am sure that if you have a problem fitting Rials on to a price tag that > the problem is not unique to Iran. The problem is not the price tags. Our Price tags are using Tomans these days, and I'm sure people should not ask for something in Unicode when they have problems with price tags. The problem is existance of the character in the national character set and on the national keyboard. --roozbeh
Re: Iranian Rial sign proposal
At 14:59 +0430 2001-04-04, Roozbeh Pournader wrote: >On Tue, 3 Apr 2001 [EMAIL PROTECTED] wrote: > >> I would think you would want this symbol to be encoded in the Currency >> Symbols block (U+20A0 through U+20CF), not in the largely deprecated Arabic >> Presentation Forms-A block. > >No, I like it in the Arabic Presentation Forms, because it's only a >ligature needed for round-trip compatiblity, it's not a real currency >sign. We are not adding characters to the presentation forms. It is likely that the answer to this proposal will be "please use one-to-many mapping". -- Michael Everson ** Everson Gunn Teoranta ** http://www.egt.ie 15 Port Chaeimhghein Íochtarach; Baile Átha Cliath 2; Éire/Ireland Mob +353 86 807 9169 ** Fax +353 1 478 2597 ** Vox +353 1 478 2597 27 Páirc an Fhéithlinn; Baile an Bhóthair; Co. Átha Cliath; Éire
Re: Iranian Rial sign proposal
On Wed, 4 Apr 2001, Roozbeh Pournader wrote: > It won't be. It's nothing more than a rendering of word Rial, sometimes > narrower to fit in one column in fixed-width fonts. It doesn't have any > international use, because it may be mistaken by Saudi Arabic Rials or > things like that. Well - the $ sign is there.. though it may be mistaken for Canadian Dollars, Hong Kong Dollars, or even American Dollars... (couldn't you tell? I was using the Australian Dollar sign :) (And even my nation's pound sign is nothing more than an L in a funny font...) The currency block is full of 'dubious' currency signs - the Rial sign would probably be in good company. ;) -- Robert Brady [EMAIL PROTECTED]
Re: Iranian Rial sign proposal
On Wed, Apr 04, 2001 at 11:03:41AM -0500, [EMAIL PROTECTED] wrote: > Given all those circumstances, maybe not. Would you propose that it have a > canonical or compatibility decomposition? If so, I believe that would be > problematic with respect to stability of normalization forms. The only thing it'll affect is the new character won't be normalized in older programs. It's not like adding Q-CARON; any program that works correctly on current text still works correctly. Since they added several hundred characters in 3.1 with compatibility decompositions, I can't see it being a problem. -- David Starner - [EMAIL PROTECTED] Pointless website: http://dvdeug.dhis.org "I don't care if Bill personally has my name and reads my email and laughs at me. In fact, I'd be rather honored." - Joseph_Greg
Re: Iranian Rial sign proposal
On Wed, 4 Apr 2001 [EMAIL PROTECTED] wrote: > So, we have some broken technology. One way to fix it is to add a > presentation form to Unicode. But isn't there another fix -- to build into > X the ability to map a key to a sequence of characters (which surely would > be useful in other situations)? Of course, adding a presentation form in > Unicode is the easier thing to do. I wonder if it's the right thing to do. The problem is that it's among the few things on key caps that do not have a character assigned yet. We will push that in X and other places that are broken, and I'm sure we will have a hard time there, simply because changing lots and lots of things only to support a key on petit Iranians' keyboards may not be economically correct... Please note that the main problem is not broken technology, but round-trip with legacy charsets. > Would you propose that it have a canonical or compatibility > decomposition? If so, I believe that would be problematic with respect > to stability of normalization forms. We are proposing a compatiblity decomposition. Why would this cause problems? --roozbeh
Re: Iranian Rial sign proposal
On Wed, 4 Apr 2001, Michael Everson wrote: > We are not adding characters to the presentation forms. It is likely > that the answer to this proposal will be "please use one-to-many > mapping". Would you please give me the reference? I once heard this, but after seeing a new proposal for "Arabic Tail Fragment" approved by UTC to be encoded in "Arabic Presentation Forms-B" block (SC2/WG2 document N2322), I thought I was wrong. We found our proposal to be stronger than that, the character was used in a national standard charset using a logical one letter to one character model, vs a presentation-based codepage like CP420 that can not round-trip even with the proposed character becuase of beasts in its positions 0x77, 0x80, 0x8B, and 0x8D. We would not have bothered these many people... But at least there's a point in getting the proposal rejected. It will get into the pipeline document so future people won't waste their time... --roozbeh
Re: Iranian Rial sign proposal
At 23:27 +0430 2001-04-04, Roozbeh Pournader wrote: >On Wed, 4 Apr 2001, Michael Everson wrote: > >> We are not adding characters to the presentation forms. It is likely >> that the answer to this proposal will be "please use one-to-many >> mapping". > >Would you please give me the reference? The resolution was taken at the Beijing meeting of WG2. >I once heard this, but after seeing a new proposal for "Arabic Tail >Fragment" approved by UTC to be encoded in "Arabic Presentation >Forms-B" block (SC2/WG2 document N2322), I thought I was wrong. (I told the committee this would happen.) The tail fragment was part of three rather old IBM code tables which were all mapped into those nasty presentation forms, and this particular glyph fragment was missing, and apparently this is causing them problems for data conversion. That, I think, wouldn't be the case for you, even if the character was used in a national character set. It's easier to map a logical character set one-to-many and many-to-one. The presentation-based model breaks because they're taking fragments and sticking them together. >We found our proposal to be stronger than that, the character was used in >a national standard charset using a logical one letter to one character >model, vs a presentation-based codepage like CP420 that can not round-trip >even with the proposed character becuase of beasts in its positions 0x77, >0x80, 0x8B, and 0x8D. We would not have bothered these many people... I'm just saying what is LIKELY to be the reaction to such a proposal. Now, if you consider it a lot more like the peseta or rupee currency symbols, and showed a glyph that really didn't look like a word, maybe. Can you do a discussion document with scans of price tags, printed samples, and so on, showing its unity and narrowness? >But at least there's a point in getting the proposal rejected. It will get >into the pipeline document so future people won't waste their time... Mmm. -- Michael Everson ** Everson Gunn Teoranta ** http://www.egt.ie 15 Port Chaeimhghein Íochtarach; Baile Átha Cliath 2; Éire/Ireland Mob +353 86 807 9169 ** Fax +353 1 478 2597 ** Vox +353 1 478 2597 27 Páirc an Fhéithlinn; Baile an Bhóthair; Co. Átha Cliath; Éire
RE: Iranian Rial sign proposal
On Wed, 4 Apr 2001, Marco Cimarosti wrote:
> U+20A3 (FRENCH FRANC SIGN), U+20A4 (LIRA SIGN), U+20A7 (PESETA
> SIGN), U+20AF (DRACHMA SIGN): will disappear next year with euro. Moreover,
> Franc and Lira are obsolete symbols ("FF" and "Lit" are now more common).
The drachma sign too; I lived in Greece from 1979 to 1983, and never saw
anything but delta chi rho, unligatured, for drachma. I've been wondering
for a fair while what it's doing there...
--
Momenton senpretende paseman mi retenis kaj # NICK NICHOLAS.
kultis kvazaux # TLG, UCI, USA.
senhorlogxan elizeon # www.opoudjis.net
(Dume: #[EMAIL PROTECTED]
[Victor Sadler, _Memkritiko_ 90] #
Re: Iranian Rial sign proposal
Roozbeh asked... > Would you please give me the reference? I once heard this, but after > seeing a new proposal for "Arabic Tail Fragment" approved by UTC to be > encoded in "Arabic Presentation Forms-B" block (SC2/WG2 document N2322), I > thought I was wrong. That proposal and this follow-on proposal for the Rial sign show clearly why it's not smart of UTC to keep letting camels' noses into the tent! At one time, the cutoff for characters getting into the standard merely because of compatibility with older, existing, or legacy standards was about 1991. The date for "legacy" keeps moving forward, and now we see that we're having to add more questionable characters for standards that are ever newer. When will this stop? If memory serves me, Unicode and 10646 were already well established at the time both this standard and the IBM standards containing "tail fragment" were created (one of the code pages shown in the proposal even has a Euro sign in it!). At least one of the IBM pages could have been created without this tail fragment, and they work around it already in Unicode interchanges. The Iraninan standards could likewise have been created without the "rial" ligature. My point is that we should really stop adding stuff like this, and people who know better should stop asking for these questionable characters. And of course, people should stop making an endless supply of new local codesets, etc... It appears that all a member company or country has to do to get whatever they want into Unicode/10646 is make up a new national or corporate standard with their thing, wait a year for it to become a "legacy", and then ask for it. Just my opinion. Other than that rant, it's probably reasonable to add the Rial sign ligature, in amongst all the other compatibility stuff in Arabic. Rick
Re: Iranian Rial sign proposal
On Wed, 4 Apr 2001, Michael Everson wrote: > The resolution was taken at the Beijing meeting of WG2. But that can be broken, can't it? (Look at the Tail Fragment case ;) > The tail fragment was part of three rather old IBM code tables which > were all mapped into those nasty presentation forms, and this > particular glyph fragment was missing, and apparently this is causing > them problems for data conversion. I can't understand them. They will also need the other parts, don't they? The other parts is not in Unicode. (Look at positions 0x77, 0x80, 0x8B, and 0x8D at the first table at the end of that proposal). > That, I think, wouldn't be the case for you, even if the character was > used in a national character set. It's easier to map a logical > character set one-to-many and many-to-one. No, we will lose lose round-trip. People will get their files corrupt. They will not like their character to be replaced by six others. Also, they may have both encodings (, and ) in their files. This is exactly the definition of a compatiblity character... Please note that while IBM Egypt people can get their programs work right by simply looking at the previous character and unify them, we cannot do that. If the convertor sees "Arabic Tail Fragment", and there is a "Final/Isolated Seen Without Tail" before that, they should convert it to "Seen+ZWNJ". If they are converting from Unicode, they should convert the final and isoalted forms of "Seen" to "Final/Isolated Seen Without Tail+Arabic Tail Fragment". But what should we when a convertor wants to convert back from Unicode to ISIRI 3342 and sees the sequence of "Reh Yeh Alef Lam" (or "ZWNJ Reh Yeh Alef Lam ZWNJ")? > The presentation-based model breaks because they're taking fragments > and sticking them together. And we have many character sets in use in Iran (the most common being Iran-System that is the de facto standard) that unify some presentation forms but not others (look at http://developer.sharif.ac.ir/farsiweb/iransystem.txt). So would you encode them? > I'm just saying what is LIKELY to be the reaction to such a proposal. I get the point. Forgive my words. I'm only confused with policies. > Now, if you consider it a lot more like the peseta or rupee currency > symbols, and showed a glyph that really didn't look like a word, > maybe. Can you do a discussion document with scans of price tags, > printed samples, and so on, showing its unity and narrowness? How can I do that when I don't believe its unity? I told you about my personal position. I don't believe it to be a real character: It's not a real currency symbol, its narrowness can be implemented in higher levels, it always looks like the word, etc. Even the standard itself used the word to represent the character in their tables (you can see that from the attached table). We only believe it to be a compatiblity character (something like half-width forms, something like Arabic ligatures, etc). HCI only wants it because we believe it will be helpful to (usually governmental) organizations that use ISIRI 3342 in their systems. You can add to that the ease of implementing the Iranian keyboard on systems with limited technologies like X. Also, since we want to create new national standards based on Unicode and ISO/IEC 10646, some of the committee members will insist that we should be backward compatible with the existing standards and not leave characters behind. (That's a hard front to fight in, if only you knew... One of them still insists on asking for disunifying Persian and Arabic letters!) > >But at least there's a point in getting the proposal rejected. It will get > >into the pipeline document so future people won't waste their time... > > Mmm. Don't tell anyone, but I would have possibly vote against it if I was not acting on behalf of HCI ;)
Re: Iranian Rial sign proposal
On Wed, 4 Apr 2001, Rick McGowan wrote: > If memory serves me, Unicode and 10646 were already well established > at the time both this standard and the IBM standards containing "tail > fragment" were created (one of the code pages shown in the proposal > even has a Euro sign in it!). At least one of the IBM pages could > have been created without this tail fragment, and they work around it > already in Unicode interchanges. The Iraninan standards could > likewise have been created without the "rial" ligature. But the day for final approval of that Iranian standard has been May 1993 (even before Unicode 1.1). The comittee should have been created long before that, they may have not heard of it, or did not understand why they should move directly from 7-bits to 16-bits with the limited software and hardware available in Iran at that time... Oh, I just found it! It's also encoded as a character in the national standard ISIRI 2900, dated 1989 (which is a 7-bit character set standard). I will update the proposal. So you can be sure that you have not disobeyed the rules ;) > My point is that we should really stop adding stuff like this, and people > who know better should stop asking for these questionable characters. Please. I'm pushing these only to be able to push Iran to adopt Unicode as /the/ standard charset. > And of course, people should stop making an endless supply of new > local codesets, etc... That's the thing I'm pushing in Iran. Not using or creating legacy codesets anymore, but using Unicode/10646 instead. > It appears that all a member company or country has to do to get > whatever they want into Unicode/10646 is make up a new national or > corporate standard with their thing, wait a year for it to become a > "legacy", and then ask for it. Please note that we have not done that. Waiting 8 years (or 12 if you count ISIRI 2900)? > Just my opinion. Other than that rant, it's probably reasonable to add > the Rial sign ligature, in amongst all the other compatibility stuff in > Arabic. Thanks... (Oh, what a marathon! I did not think it will be this hard. Next opponent please! ;))) --roozbeh
Re: Iranian Rial sign proposal
Roozebeh wrote... > Oh, I just found it! It's also encoded as a character in the national > standard ISIRI 2900, dated 1989 (which is a 7-bit character set standard). > I will update the proposal. So you can be sure that you have not disobeyed > the rules ;) Oh good! Nice bit of research...! This much legitimizes the character... ;-) > Please. I'm pushing these only to be able to push Iran to adopt Unicode as > /the/ standard charset. Yes, I believe you. That's why I commented at the end... "it's probably reasonable to add the Rial sign ligature"... But of course now you can show that it was in use as early as 1989. Rick
RE: Iranian Rial sign proposal
At 19:50 +0430 2001-04-04, Roozbeh Pournader wrote: >I noted that, but the point is that it's not a unique sign for >international use. It's only a compatiblity character, and it will be used >only in "legacy" Persian texts that are converted from ISIRI 3342 (which >has its own bidi, with only three categories: Left-to-right, >Right-to-left, and Persian Number). What's this mean? That in Word 200x, with full Persian support, you would not use a unitary code point for the rial sign, but instead you expect users only to type the four letters that make up the word? >And then it made its way into the national standard character set. And now >we need it for round-trip. And we do want to discourage its use in all >ways (unless unavoidable), and we want to mark it as deprecated in all >ways. Then your solution is that your round-trip is achieved by a mapping table that maps one-to-many and many-to-one depending on direction. -- Michael Everson ** Everson Gunn Teoranta ** http://www.egt.ie 15 Port Chaeimhghein Íochtarach; Baile Átha Cliath 2; Éire/Ireland Mob +353 86 807 9169 ** Fax +353 1 478 2597 ** Vox +353 1 478 2597 27 Páirc an Fhéithlinn; Baile an Bhóthair; Co. Átha Cliath; Éire
RE: Iranian Rial sign proposal
On Wed, 4 Apr 2001, Michael Everson wrote: > What's this mean? That in Word 200x, with full Persian support, you > would not use a unitary code point for the rial sign, but instead you > expect users only to type the four letters that make up the word? No. The keyboard mapper should generate the four characters (or possibly six, with the two non-joiners) when the user presses Shift-4. We will recommend this in our next national keyboard standard. Microsoft Persian keyboard, available in Windows 2000, already supports this idea on its shift-R. It produces the four letters. There is a possible need for distinguishing the two in some applications or environments (they may want the narrower shape for example), and we will leave to them the choice of using the Rial character or some higher level standard. > Then your solution is that your round-trip is achieved by a mapping > table that maps one-to-many and many-to-one depending on direction. -- No. Such a mapping table does not respect the difference between the Rial sign and the string "Reh Yeh Alef Lam" in the ISIRI 3342 encoded file. (BTW, I just saw your grass radicals proposal. I can understand many things now, including why you hate compatiblity characters :))) --roozbeh
RE: Iranian Rial sign proposal
At 06:09 +0430 2001-04-05, Roozbeh Pournader wrote: > > Then your solution is that your round-trip is achieved by a mapping > > table that maps one-to-many and many-to-one depending on direction. -- > >No. Such a mapping table does not respect the difference between the Rial >sign and the string "Reh Yeh Alef Lam" in the ISIRI 3342 encoded file. Why would you want to preserve that distinction, if you are satisfied to use the string only in Unicode text? -- Michael Everson ** Everson Gunn Teoranta ** http://www.egt.ie 15 Port Chaeimhghein Íochtarach; Baile Átha Cliath 2; Éire/Ireland Mob +353 86 807 9169 ** Fax +353 1 478 2597 ** Vox +353 1 478 2597 27 Páirc an Fhéithlinn; Baile an Bhóthair; Co. Átha Cliath; Éire
RE: Iranian Rial sign proposal
Michael Everson wrote: > At 06:09 +0430 2001-04-05, Roozbeh Pournader wrote: > >No. Such a mapping table does not respect the difference > between the Rial > >sign and the string "Reh Yeh Alef Lam" in the ISIRI 3342 > encoded file. > > Why would you want to preserve that distinction, if you are satisfied > to use the string only in Unicode text? There are many usages for Unicode; one of them is acting as the internal representation of text in *internationalized* LOW layers of software, as opposed to *localized* HIGH layers using legacy charsets. The "low layer" (using Unicode) is things like operating system API's, database engines, network transport components, etc. The "high level" (using legacy charsets) is things like keyboard drivers, plain text files, fonts, etc. This is, e.g., the way Windows NT works: Unicode is used to handle text in the OS core, but it is mapped to/from "code pages" as soon as it has to become visible to the user. But if the mapping is not faithful in both directions, the user is going to have problems. Especially, irreversible one-to-many mappings may be dangerous because you may drive old applications to violate size limits. Take the example of Iranian rial. An old application running on an old operating system used this character in a single-character field . When the application is ported to a newer operating system, which uses Unicode internally, it will break because it will attempt to insert a 4-character string in that 1-character field. The programmer reviews the code and gets puzzled, because she sees that the program actually puts 1 character there! So who changes it to a 4-character word? Sooner or later, she will discover that it is the Unicode conversion inside the operating system that causes this problem, and she will of course blame Unicode -- who else? My natural reaction to such a story would be: "Why don't you fix that bloody program? How can a field be limited to 1 character? What will you do with 'FF', 'DM', 'L.', 'US$', 'GB£', etc.?" And that is also my first reaction with X keyboards: just go and change them to allow an arbitrary string to be attached to each key. But I know that, in practice, it is not always possible to do these "small" fixes. The existing software base can be enormous, and fixing all of it may be very complicated. Do you remember the millions dollars and man/hours lost to fix the Y2K bug? Well, that was the most stupid bug I have ever heard of: it simply required that all 2-digit year fields be changed to 4 digits... _ Marco
Re: Iranian Rial sign proposal
From: "Marco Cimarosti" <[EMAIL PROTECTED]> > This is, e.g., the way Windows NT works: Unicode is used to handle text in > the OS core, but it is mapped to/from "code pages" as soon as it has to > become visible to the user. Well, not exactly though. NT works best when you use Unicode everywhere, both high and low level. For backwards compatibility they provide a second set of APIs that does mapping everywhere, but it is mapped way down at the API level, using these back. compat APIs. It does make you want to come up with another set of terms other than "high" and "low" since implying that the non-Unicode way is "high" almost seems wrong! NT is definitely at its best when use Unicode at all levels. Especially in places like Farsi which have no code page that can be used for all characters! MichKa Michael Kaplan Trigeminal Software, Inc. http://www.trigeminal.com/
RE: Iranian Rial sign proposal
On Wed, 4 Apr 2001, Michael Everson wrote: > Why would you want to preserve that distinction, if you are satisfied > to use the string only in Unicode text? I'm satisfied, but there will be transition periods. Two organizations that have adapted Unicode externally, buy not internally yet, will have problems with this. We will give them our standard tools for converting to and from ISIRI 3342, but the data will be changed after passing through this filter. --roozbeh
RE: Iranian Rial sign proposal
Michael (michka) Kaplan wrote: > Well, not exactly though. NT works best when you use Unicode > everywhere, both high and low level. For backwards > compatibility they provide a second set of APIs that does > mapping everywhere, but it is mapped way down at the API > level, using these back. compat APIs. Yeah. Pity that the local code page is the default everywhere, and to use Unicode in the GUI one has to dig deep in options, registry, manuals, etc. And that's not enough, anyway. I still have to discover how to display Unicode in Visual Basic, for instance. Someone should write a book about this. ;-) > It does make you want to come up with another set of terms > other than "high" and "low" since implying that the > non-Unicode way is "high" almost seems wrong! If "high" and "low" have the usual meanings of "nearer to the user" and "nearer to the hardware", respectively, then I think that what I said is true for NT and many other environments. And truth is never wrong. _ Marco
Re: Iranian Rial sign proposal
From: "Marco Cimarosti" <[EMAIL PROTECTED]> > Yeah. Pity that the local code page is the default everywhere, and to use > Unicode in the GUI one has to dig deep in options, registry, manuals, etc. Well, I would not go *that* far in theory just defining _UNICODE is all you need. How far an app is from that theory varies, but its a measureable (and costable!) issue. > > And that's not enough, anyway. I still have to discover how to display > Unicode in Visual Basic, for instance. Someone should write a book about > this. ;-) There's an idea. :-) > If "high" and "low" have the usual meanings of "nearer to the user" and > "nearer to the hardware", respectively, then I think that what I said is > true for NT and many other environments. Well, like I said, the apps that stay Unicode throughout are ones that I would consider to be ideal. And then if you take wrapper implementations like the one in Avery Bishop's white paper then you have a quite classic reversal on Win9x: the low level non-Unicode and the high-level Unicode interface. > And truth is never wrong. But it also never stays the same. MichKa Michael Kaplan Trigeminal Software, Inc. http://www.trigeminal.com/
RE: Iranian Rial sign proposal
Michael (michka) Kaplan wrote: > From: "Marco Cimarosti" <[EMAIL PROTECTED]> > > Yeah. Pity that the local code page is the default > everywhere, and to use > > Unicode in the GUI one has to dig deep in options, > registry, manuals, etc. > > Well, I would not go *that* far in theory just defining > _UNICODE is all you need. How far an app is from that > theory varies, but its a measureable (and costable!) issue. I assume that you are not talking about the point of view of an end user or a system administrator, as "defining _UNICODE" would mean nothing to them. But, even for a programmer, it is not as simple as "defining _UNICODE". A medium size project normally involves several aspects: - Writing code in C(++); - Writing code in other languages (including SQL or scripting languages); - Using ready made software (editors, programming environments, utilities, etc.); - Using ready made code (libraries, DLLs, 3rd party controls, etc.); - Using database engines directly or through connectivity object; - Moving text through networks (including Web and e-mail); - Last but not least, using command line based scripts or commands. The level of Unicode support in all these things, and the level of dependency on code pages, varies a lot. Some things support Unicode, some don't; some nicely convert to and from code pages, some are more clumsy; for some things you need to do certain things to set up Unicode support, for some others you do totally different things; some things see Unicode as a "16-bit character set", some other things are more up-to-date with UTF's. We are talking about Windows NT, but I don't think that the situation is much different on other systems. > Well, like I said, the apps that stay Unicode throughout are > ones that I would consider to be ideal. That's clear, but we were discussing about round-trip convertibility between Unicode and another standard, so Unicode-clean application clearly don't apply here. > > And truth is never wrong. > But it also never stays the same. But also it doesn't change overnight. I think that local character sets will be with us for years to come. Potentially, we will have to deal with them forever: if we need to read Linear B tablets in year 2001, I don't see why our nephews in year 2999 should not need to read old e-texts in Shift-JIS or ISIRI 3342. Mmm... Perhaps I should amend what I just wrote: almost no one in 2001 has ever seen a Linear B tablet and, probably, would never have the possibility of touching one. But everybody can go in a bookshop and buy a *paper* book *printed* with reproductions of Linear B tablets. This is because the technology has evolved and we now have paper in place of clay, and printing in place of manual copying. Similarly, the new technology must be able to reproduce and bring forward the documents produced with older technologies. If it was not for this need, I would be the first one to shout that a big percentage of Unicode code points is just crap that could be wiped out. Unluckily we also have to deliver the crap to posterity, just like clay tablets talk us about slaves and human sacrifices... _ Marco
RE: OT obsolete symbols was: Iranian Rial sign proposal
D.V. Henkel-Wallace wrote: > At 16:03 2001-04-04 +0200, Marco Cimarosti wrote: > > > U+20A5 (MILL SIGN): which currency is so worthy to > require a special > >symbol for 1/1000? > > > >And it is also true for many currency symbols in other blocks: > > > > U+00A4 (CURRENCY SIGN): who ever used this? > > Both are (/were ?) used in banking; MILL for basis points. > Next time you fly, peek at the reservation screen and you'll see the > currency symbol overloaded there too. > I still read books that use shillings and half crowns; should > I excise that now-obsolete system of my childhood? Perhaps I didn't make my point: I was not discussing whether those symbols have to be in Unicode or not. Of course obsolete currency symbols *are* necessary -- at least until the last electronic contract, payroll, or retirement record using that symbol exists. (For what concerns the Lira Symbol, please don't remove it until my last wills are open. I don't want my heirs to inherit a few millions question marks. :-) I was rather meaning that many of the characters in the Currency Symbols block have only a legacy significance, and thus, Roozbeh's Rial sign could stay in that block too. _ Marco
RE: OT obsolete symbols was: Iranian Rial sign proposal
Marco, >(For what concerns the Lira Symbol, please don't remove it >until my last wills are open. I don't want my heirs to inherit >a few millions question marks. :-) A good example of an obsolete currency mark is the Brazilian Cruzeiro. (u\20A2) They kept that one. Your problem will be finding a font that will support it. I suggest that you amend your will and change it to Euros. Carl -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Marco Cimarosti Sent: Wednesday, April 04, 2001 11:29 AM To: Unicode List; 'D.V. Henkel-Wallace' Subject: RE: OT obsolete symbols was: Iranian Rial sign proposal D.V. Henkel-Wallace wrote: > At 16:03 2001-04-04 +0200, Marco Cimarosti wrote: > > > U+20A5 (MILL SIGN): which currency is so worthy to > require a special > >symbol for 1/1000? > > > >And it is also true for many currency symbols in other blocks: > > > > U+00A4 (CURRENCY SIGN): who ever used this? > > Both are (/were ?) used in banking; MILL for basis points. > Next time you fly, peek at the reservation screen and you'll see the > currency symbol overloaded there too. > I still read books that use shillings and half crowns; should > I excise that now-obsolete system of my childhood? Perhaps I didn't make my point: I was not discussing whether those symbols have to be in Unicode or not. Of course obsolete currency symbols *are* necessary -- at least until the last electronic contract, payroll, or retirement record using that symbol exists. (For what concerns the Lira Symbol, please don't remove it until my last wills are open. I don't want my heirs to inherit a few millions question marks. :-) I was rather meaning that many of the characters in the Currency Symbols block have only a legacy significance, and thus, Roozbeh's Rial sign could stay in that block too. _ Marco
