Re: Unicode 6.2 to Support the Turkish Lira Sign

From: Asmus Freytag <asmusf_at_ix.netcom.com>
Date: Tue, 22 May 2012 13:36:00 -0700

This came out of an offline discussion, but I answered this in some
detail and think it's useful to have this associated with the discussion
on the list.

A./

On 5/22/2012 12:40 AM, Andreas Stötzner wrote:
>
> Am 22.05.2012 um 07:13 schrieb Asmus Freytag:
>
>>
>> There is an early precedent, going back to the Euro sign, of Unicode
>> adding a new character instead of "repurposing" any existing
>> character that may seem to be unused.
>>
>> The principle there is, that until a particular currency gets
>> actually created (or a specific symbol is officially adopted for an
>> existing currency) whatever character already exists in Unicode is
>> for "something else". It may be unclear precisely what it is to be
>> used for, but it is clear that it is *not* to be used for the new symbol.
>
> The Turks did not present “a new symbol”. They presented a new design
> for an existing symbol (₤) which stands in for an existing currency.

A new design makes it a new symbol. Especially a radical new design.

> The fact that they deny the previous existence of that symbol (or that
> they just overlooked it) cannot be taken as prescriptive for
> international standards bodies. 20A4 is defined as LIRA sign. That
> does by no means exclude a usage for “Turkish Lira”, on the contrary,
> the character is devised for such very usage.

No, the character code is not a "placeholder" for any designation for
the Turkish lira whatsoever, it's tied to the type of typographical
design commensurate with the representative glyph shown at 20A4.

> Compare: $ is defined as DOLLAR sign and it is devised for a dozen of
> currencies worldwide, in a variety of different designs. But the
> design aspect is of mere graphical interest here. So it is with the
> Lira: let them have their favorite design in peace, but that does not
> raise a character encoding case.

It designates not only Dollar, but also currencies named peso. Yet, if
any of these currencies want a different shape, they will have to get a
new symbol, because U+0024 is tied to $ (or explicitly also S with
double or discontinuous vertical strokes). A hypothetical design using a
barred P for any of the Peso currencies would not be unifiable with the
$ and require a new symbol....and that's precisely what happened with 20B1.
>
>> So, there's absolutely no point in discussing whether or not some
>> glyphs should change - that's flat out.
>
>>
>> This is different from using an existing character for a symbol that
>> does look like that character (e.g. if some currency were to adopt
>> the shape "$" as a symbol, then U+0024 would be the character to use,
>> irrespective of the name of the currency in question).
>>
>> The identity of symbols, and that includes currency symbols, is
>> largely defined by appearance, much more so, than is the case for
>> letter shapes. Changing "glyphs" for a symbol really means changing
>> its *identity*, and that goes against the character code stability
>> policy in a rather direct way.
>
> The new design presented by Mr Erdogan is – *definition!*: a < L with
> two crossbars >. That is sufficiently represented by the codepoint
> 20A4 and the glyph ₤. We claim: “glyphs in the charts are not
> prescriptive”.
> Currency glyphs of design contests aren’t descriptive either.
> I cannot see any need for a new codepoint for a variant glyph of ₤.

The principle is that unifiable glyph variants should be such that they
can be substituted without altering the meaning of the text. That's
patently not the case here. You can't use the old design for designating
Lira under the new policy. And the Turkish policy expressly intends that
the Lira sign be recognizable the "new" shape (with ordinary
typographical variation).

A pound sign £ can also not be substituted by just any barred L.
Otherwise U+023D Ƚ would serve and there wouldn't be a need for U+00A3
£. The recognition that the "script" shape for the £ is part of the
design goes as far back as German and other typewriter keyboards, which
had a key for it, while any typist would have been able to create an Ƚ
simply by overstriking an L with a hyphen.

I think these precedents show beyond a reasonable doubt that even for
letterlike symbols (which these currency symbols are) it's not enough to
define the symbol based on the letter skeleton alone - nor is it correct
to tie currency symbols arbitrarily to one national currency - thus
letting the shape "drift" with changes in usage for that currency.

>
>> The reason why symbols are different from letters in this respect is
>> the fact that they don't have a word-context. When you see the symbol
>> displayed or printed, pretty much the only clue you have as to its
>> identity is the shape. That rather dramatically restricts possible
>> variations in appearance.
>
> In writing currency glyphs undergo the same variations like other
> letters. Most currency symbols are derivatives from alphabetical
> glyphs. They form a class of signs of their own but typographically
> they are subject to shape alteration just like letters.

I fully agree with this: letterlike symbols are, by definition, subject
to *normal* typographic variation, such as italic, sans-serif etc. That
is, they are harmonized with the remaining text which happens to be set
in the same typeface. This principle is not absolute: £ or ₤ are
exceptions, because the "script" nature of the L is part of the design
and is therefore reproduced as far as necessary even in the context of
sans-serif, roman and other typestyles. (And also the €. while varied
with typestyle, is not based on a "standard" capital E, but retains its
rounded spine across type faces).

For the new Lira sign: even in a script typeface, it would not look like
₤. So, you have to conclude, it's rather a different animal.

That is, if you follow established, character coding precedent in doing
your analysis. If all of a sudden, you re-analyze this symbol using
different principles, you are doing nobody a favor, because not only
would you violate the stability guarantees but the very expectations of
your users. Not to mention, creating unnecessary headaches for people
trying to sell fonts and applications that deliver what's expected
without changing an unknown number of past documents.

This does not mean that the style of analysis done in the context of a
character encoding is the only possible style of analysis - merely that
it's the one style of analysis appropriate in settling character
encoding questions.

A./
Received on Tue May 22 2012 - 15:41:05 CDT

This archive was generated by hypermail 2.2.0 : Tue May 22 2012 - 15:41:11 CDT