Re: Indian Rupee Sign (U+20B9) proposal

From: Asmus Freytag (asmusf@ix.netcom.com)
Date: Mon Jul 19 2010 - 15:21:23 CDT

  • Next message: Tulasi: "Re: Indian Rupee Sign (U+20B9) proposal"

    On 7/19/2010 11:26 AM, Doug Ewell wrote:
    > 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
    > meant for:
    >
    > D49: "... the abstract characters associated with [private-use code
    > points]... can be given any interpretation by conformant processes."
    >
    Correct. But this is not the case of someone "testing out" a symbol, or
    creating documents that are "privately" exchanged.

    The real danger for a currency symbol is that any "temporary" solution will
    a) pollute a lot of data (that need to be visible from future systems)
    b) will not be supplanted fully, i.e. continue to coexist, creating an
    ongoing mess.

    Why are currency symbols special?

    Once they get adopted, nearly every user will use them, all the time,
    and in all manners of documents. Therefore any "temporary"
    implementation will be widespread (and not private).
    > Overloading U+0060 or U+20A8 breaks a fundamental rule of Unicode: don't
    > change the basic identity of a character.
    Correct, these two, in order, describe the worst and second worst scenario.
    > 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 case of the PUA, applications will happily display whatever character
    they *assume* is assigned to that PUA location. For many applications
    that might be an entirely different character. Worse, if a PUA-based
    implementation catches on and continues to exist for a while, other
    implementations may be forced to recognize that PUA assignment - in the
    worst case in perpetuity.

    We all know of examples of this from East Asia.
    >> 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.
    >
    Correct, you can't implement a conformant solution, but of all the
    non-conformant solutions that you mention, this is the best choice,
    because of the problems I mentioned. In a later message in this
    discussion I qualified my recommendation by saying "at the earliest
    possible time". I think that you'd want to at least wait for the first
    stage of processing of this proposal in the relevant committees, before
    hazarding any implementation...

    And the committees might want to find a way to create early ways to
    implement this character in a conformant way. That won't happen on this
    mailing list, so let's wait for the next meetings (August and October).
    > 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
    > possible.
    >
    >
    Look, like you, I don't know first hand, what the real pressure is to
    adopt this thing. Normally, when you have legislative reforms of
    anything, whether orthography or currency, then you also get
    implementation deadlines. No legislative body will defer to a mere
    standards organization, whether ISO or Unicode in setting these
    deadlines (and I don't think politicians in India are any different than
    the world over on that). It the change isn't mandatory, but voluntary,
    then they may not have bothered to set a deadline. That might be the
    case here, so the race is on to be the first to get this done and score
    some points with the local community.

    In any case, this is an example of a "real world" event, one that has
    it's own dynamics, and the character set standardizers either get in
    front of it, or out of the way. You may not like it, but realistically,
    that's how it goes.

    A./
    > --
    > 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 - 15:25:09 CDT