From: Jonathan Rosenne (email@example.com)
Date: Mon Jul 19 2010 - 01:12:02 CDT
I think that this day and age, and in view of the importance and urgency of
the issue as pointed out by several, there is no reason why both Unicode and
ISO could not nor should not conduct an e-mail vote on Michael's proposal
and be done with it.
> -----Original Message-----
> From: firstname.lastname@example.org [mailto:email@example.com] On
> Behalf Of Asmus Freytag
> Sent: Monday, July 19, 2010 8:21 AM
> To: John H. Jenkins
> Cc: unicode List
> Subject: Re: Indian Rupee Sign (U+20B9) proposal
> On 7/18/2010 8:31 PM, John H. Jenkins wrote:
> > ÔÚ Jul 18, 2010 4:32 PM •r£¬ Doug Ewell Œ‘µ½£º
> >> Michael Everson <everson at evertype dot com> wrote:
> >>> So you're saying they'd be better off just putting it at U+20B9? :-
> >> 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
> will create long term compatibility problems if it gets deployed
> A currency symbol is different from an oddball punctuation character.
> It has a high degree of initial legitimacy as a symbol (because it's
> government endorsed) and it has a ready-made audience - coupled with
> competitive pressure to be the first with a "solution".
> 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.
> >> One of the posts on the Foradian blog congratulates the font vendor
> for adding the new symbol at U+0060 and thus "exhibit[ing] the IT
> knowledge power of YOUNG INDIA." This kind of slap-dash, font-hack
> solution is not the hallmark of a young, vibrant, knowledgeable IT
> community. It is the hallmark of an IT community that is disdainful of
> standards and ignorant of the short- and long-term problems caused by
> incompatible, quick-fix encoding solutions.
> No argument there. Overloading an existing code point, whether U+0060
> U+20A8 or even U+005C is to not understand the interconnectedness of
> modern distributed systems. It's decidedly antediluvian.
> >> It's also interesting to see the posts that criticize the Indian
> government for predicting it will take a year for the new symbol to
> achieve widespread usage, countering smugly that Foradian was able to
> create its font in a matter of days. Anyone who thinks that is all
> that is necessary for a symbol to achieve widespread usage is speaking
> volumes about their own level of knowledge.
> If the creation of the symbol resonates with the public then yes,
> widespread use could happen as soon as there's support. The whole issue
> of creating a new symbol is a matter of status-envy (compared to $, €,
> and other major currencies). That motivation can be a strong driving
> force for adoption, if it's shared by the user community, and not just
> by their legislators.
> > Very well said, Doug. The question I'm curious about is, What is the
> most productive way to help the people advocating this approach
> understand that it's a bad idea?
> I would put it differently. What is the best and most productive way to
> help the user community avoid compatibility issues or worse, competing
> implementations with different solutions.
> In this instance, as was done for the Euro, I would advocate option (3)
> from the earliest possible moment.
> Aside: The Euro gave Unicode and the users the luxury of a bit more
> breathing room, because it was tied to a timeline for adopting and
> converting to the currency itself, but the eventual code point was made
> known quite a bit in advance to prevent people from overloading U+20A0.
> And, at that time, and for that region, the use of 8-bit standards was
> still very common, which provided a whole different dynamic.
This archive was generated by hypermail 2.1.5 : Mon Jul 19 2010 - 01:16:24 CDT