From: Erkki I Kolehmainen (email@example.com)
Date: Mon Jul 19 2010 - 14:51:21 CDT
I tend to agree with Asmus on this one, too.
A comment to Doug's last para: At the time when the euro symbol was introduced, there was quite some opposition (also within several European ISO National Bodies) to encoding it, because "we don't need any currency symbols, since they are replaced by the currency codes". The euro symbol, however, has gained widespread use, which is the reason for other currencies seeking similar recognition.
Incidentally, there is a large number of currency symbols/abbreviations, as shown in the CLDR data. Most of them, however, are only applicable for limited localization, since they would be unrecognizable to most users in other countries (and thus should be avoided).
Lähettäjä: firstname.lastname@example.org [mailto:email@example.com] Puolesta Doug Ewell
Lähetetty: 19. heinäkuuta 2010 21:26
Aihe: Re: Indian Rupee Sign (U+20B9) proposal
Asmus Freytag <asmusf at ix dot netcom dot com> wrote:
>>> No, I'm saying that if they really need a solution this instant, they'd be better off adhering to the Unicode Standard and 10646, and putting it in the PUA rather than (1) overloading U+0060, (2) overloading U+20A8, or (3) putting it at U+20B9 before that code point is formally assigned.
> I disagree in this instance. Any use of "temporary" code point assignment, whether it follows the rules (PUA) or doesn't (case 1 and 2) will create long term compatibility problems if it gets deployed widely.
But temporary code point assignment is one of the things the PUA is
D49: "... the abstract characters associated with [private-use code
points]... can be given any interpretation by conformant processes."
Overloading U+0060 or U+20A8 breaks a fundamental rule of Unicode: don't
change the basic identity of a character. At least if the PUA is used,
it will be evident that the code point is meant to be temporary. In
cases 1 and 2, applications will happily display ` or ₨ without
knowing that the 2010 version of the rupee sign is intended instead.
> In my view, this is the kind of exceptional solution where the best course is to pre-implement the "final" code point assignment. That will create the least amount of long-term problems.
Considering the impressive amount of experience that Asmus has with the
UTC/WG2 encoding process, if he feels sufficiently confident that
vendors are safe in pre-implementing U+20B9, I'm in no position to say
otherwise. But it does violate conformance requirement C3.
Strange that both the Indian rupee and the concept of currency symbols
have existed for so long, with comparatively little drama over the lack
of a unique currency symbol for the Indian rupee, but now that one has
been defined, it's worth violating standards to implement it as fast as
-- Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org RFC 5645, 4645, UTN #14 | ietf-languages @ is dot gd slash 2kf0s
This archive was generated by hypermail 2.1.5 : Mon Jul 19 2010 - 14:52:51 CDT