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./




Reply via email to