On 5/29/2012 12:00 PM, Doug Ewell wrote:
> Asmus Freytag<asmusf at ix dot netcom dot com> wrote:
>
>> Sovereign countries are free to decree currency symbols, whatever
>> their motivation or the putative artistic or typographic merits of
>> the symbol in question. Not for Unicode to judge.
>>
>> The simple fact is, the usage scenario for currency symbols is such
>> that immediate availability as character code is required by a whole
>> country (and its partners in commerce).
>>
>> Kvetching doesn't make a difference, it just reflects badly -
>> especially if it comes from anyone whose country happens to have its
>> currency "covered".
> Asmus, there's no "ugly American" motivation at work here. I don't mind
> one bit if Turkey wants a currency symbol, although I hope for their
> sake they are realistic about the benefits such a symbol will bring.
That part of the discussion is really out of scope here. Sovereign
nations are free to
introduce currencies as well as symbols - just like they are free to
adopt orthographies.
All of these events, because they affect such high percentage of users
in a country
simultaneously, will produce pressure for immediate technological solution.
> I was specifically, and only, referring to a character proposal—any
> proposal—being dubbed "urgent" on the basis that a font hack has been
> identified.
Every paragraph of your message was about or related to currency
symbols, so pardon
me for not getting that your message was generically about the font hacks.
That aside, not every font hack leads to an equal pressure on encoding.
However, in the context of widely used symbols, font hacks, as well as
PUA encodings
are to be avoided at all costs - they have the potential to corrupt data
for years to come
(data never changes - see Roozbeh's post).
>
> N3862 for the Indian rupee sign says:
>
> "A UCS codepoint assignment for this character is urgent. Already at
> least one font has been published which puts the character’s glyph at
> U+0060 GRAVE ACCENT."
>
> N4258 for the Turkish lira sign says:
>
> "A UCS codepoint assignment for this character is urgent. Already at
> least one font has been published which puts the character’s glyph at
> U+00A8 DIAERESIS."
>
> We will have to wait and see whether proponents of new characters in the
> future (not necessarily currency symbols) distribute their own ASCII or
> Latin-1 font hacks in an attempt to speed up the UTC and WG2 encoding
> processes.
A more sane approach would be to explicitly recognize the unique
situation of widely
used symbols (or, more precisely, symbols that can be confidently
predicted to be widely
used based on official adoption with or without a deadline).
Even with that, it will be a bit of a judgement call, because some
efforts at launching such
symbols either never really take off, or they don't take off at a date
as early as seems
initially the case, so a bit of caution is OK. But one really shouldn't
have to "justify" each
and every currency symbol on its inherent merits as if there hadn't been
a precedent.
And certainly, waiting to see whether there are non-Unicode solutions
for it is counter
productive.
But the way the procedures have evolved, they work best for symbols and
scripts where
there's no immediate pressure to deploy them widely practically from the
get go.
Over the next decades of Unicode's lifetime, there will be other cases
where "waiting
how things play out" may not be feasible. At some point, somebody,
somewhere is going
to reform an orthography to the point of requiring a ton of new
characters, or a new
script. The history of writing systems will not stay still, just because
of Unicode.
When that happens (for other than tiny communities) Unicode will be
presented with
similar pressure to adopt the encoding "before demonstrated actual use".
It's just
in the nature of things.
Luckily, those events are rare, but they can be expected. It would be
worth covering
that situation explicitly in the relevant procedures, so that proposals
don't have to
be written in a style suitable for "discovered" or "emerging" characters
and writing
systems, but in a style suitable for "changes to high frequency usage".
A./
Received on Tue May 29 2012 - 18:14:41 CDT
This archive was generated by hypermail 2.2.0 : Tue May 29 2012 - 18:14:53 CDT