Re: Unicode 6.2 to Support the Turkish Lira Sign

From: Andreas Sttzner <as_at_signographie.de>
Date: Wed, 23 May 2012 00:20:36 +0200

Am 22.05.2012 um 22:36 schrieb Asmus Freytag:

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

– it should have gone to the list, my fault –.

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

What makes a symbol a symbol?

If I design a new door handle, is this going to get a new rubrication in household supplier’s catalogues? Or is it still just: a door handle.
And how would you define or measure the radicalism of the design in question?
I can’t see any ‘radical new design’.

        Which labouring for invention bear amiss
        The second burthen of a former child!
                                (W. Sh., Sonnet LIX)

And IF it is a new symbol, that does not imply neccessarily that it has to be a new character.

We are about to set a precedent of a poor re-design of an existing well-bred character-glyph making the case for claiming “a new character”.

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

And I say: the new Turkish design is not convincingly enough different from the 20A4 glyph model, to claim rightfully new char. status on grounds of that reasoning.

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

Are you encouraging the Dollar/Peso countries awaking now and demanding their own respective tweaked and twisted – “designed!” – barred-S / crossbared-P sign-glyph-symbol-character?
Are we going to open up that bottle?

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

Yes I can. Most will comprehend.

But this is the point: we are going to encode *policy designs* now, not just characters any more.
Well if this is the way to go we’ll have to face it.

> And the Turkish policy expressly intends that the Lira sign be recognizable the "new" shape (with ordinary typographical variation).

A serious proof of the new design’s veracity and reason would have been a depiction in at least three typical Roman type styles, demonstrating it’s relation to the existing ₤-model in detail. This would be the stage where you can be convincing about the new symbol’s nature. But we didn’t see anything of the kind so far.

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

– but this is exactly what is just going to happen now, if I understand roughly. –

> 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

I’d rather say it is not part of the design, but: it is part of the symbol’s nature. The difference makes sense as I can apply very many different ‘designs’ to that particular aspect of it’s nature.
But maybe I’m going too far now.

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

It will presumably always be in high danger of looking very much like ₤. It’s everything but safe from this. This is because the Turks didn’t sort out the relevant questions and we hesitate to ask.

There are reports that some people already mixed the new design with the Euro symbol. That so far about “a new design” becoming a case for “a new character”.

The actual problem is the design’s ambiguity. WHAT is it? What is it not? Who is going to tell us?
“It’s a new symbol” – I don’t buy. Not in a case like this.

For the ₤ we can define EXACTLY what it is: a scriptive capital Latin L with a double crossbar, in this very combination standing in for the term “Lira” (derived from Latin “libra”), meaning a monetary unit of that same name.
Give me a likewise neat definition of the new symbol which makes sense and I’ll go for it.

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

I’m one of those who have to care not only about selling but also about designing fonts before selling them. And this is where *my headaches* come from. Because design, for me, is connected to thinking. Or, in other words: to comprehend shapes. (yes I’m rather serious about this)

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

I’m fully aware of the issue and I respect (and understand) the aim of being practical, helpful and to secure distinctions wanted. I’m also generally fond of the idea of introducing new characters if there is a case for it. But here, I fear, we’re buying too quickly and too cheep.

Best,
        Andreas Stötzner.
Received on Tue May 22 2012 - 17:24:36 CDT

This archive was generated by hypermail 2.2.0 : Tue May 22 2012 - 17:24:48 CDT