Agile Processing for Standard Encoding of New Currency Signs (was: Re: Unicode 6.2 to Support the Turkish Lira Sign)

From: Ken Whistler <kenw_at_sybase.com>
Date: Wed, 23 May 2012 10:51:44 -0700

On 5/23/2012 7:05 AM, William_J_G Overington asked:
> For example, if a situation arose where a fast timetable is set for introducing one or more new currencies, each with a new currency symbol, is there a contingency plan in place such that what is preently set to be called Unicode 6.2 becomes called Unicode 6.3 and a document labelled Unicode 6.2 with just the one or more new currency symbols within it is published within a time period such that fonts can be made and put into use before the "fast timetable" needs them to be available?

Both the UTC and SC2/WG2 are well aware of the process issues involved
in trying to deal with the encoding needs and urgent timetables resulting
from the current fad for governments to invent new currency symbols
(for whatever reason).

The UTC has a project to figure out how to accelerate approvals and
publication for these cases, because they are acutely aware of the
implementation
bind that these additions create for IT companies. The updating of fonts
is actually the lesser part of the problem. Getting support for the
processing
of the new character into software is what causes the main headaches,
because of the very short lead times involved.

The UTC knows this problem isn't going to go away. The Turkish lira sign is
only the most recent example. The new Indian rupee sign was added in
Unicode 6.0. The new Armenian dram sign was added in Unicode 6.1.
Azerbaijan has an as-yet-unecoded new symbol
for their manat currency, and everybody expects Russia to get around to
approving a new currency symbol for the ruble one of these days.

--Ken
Received on Wed May 23 2012 - 12:53:38 CDT

This archive was generated by hypermail 2.2.0 : Wed May 23 2012 - 12:53:38 CDT