From: Asmus Freytag (asmusf@ix.netcom.com)
Date: Wed May 24 2006 - 18:27:10 CDT
On 5/24/2006 1:20 PM, Sinnathurai Srivas wrote:
> Seeing the following in the mail below,
>
> " The use of left/right in the character names (corresponding to
> opening/closing in the earlier Unicode 1.0 names) are somewhat
> unfortunate in this respect. (They are, of course, a side effect of
> the cultural bias of the initial group of standardizers, but that's
> not the point here)."
>
> I'm of the opinion that "No correcting errors pact" alias "Stability
> pact" is only applied to less powerful language communities and not to
> overpowering communities for fear of loosing wages. Is ISO justified
> in doing this?
The merger between Unicode and ISO/IEC 10646 resulted in several
non-compatible changes between Unicode 1.0 and Unicode 1.1. These
changes in the early infancy of the standard are well motivated by the
benefit of that merger (i.e. not having multiple incompatible standards).
In case of names, by the way, ISO/IEC JTC1/SC2/WG2 only adopted a formal
stability policy after several smaller countries succeeded in lobbying
for changes in a few character names, which were felt to have been very
disruptive to the implementers and user communities. In other words, the
working group based its policies on first hand experienced the
deleterious effects of such changes.
That was at a time when there were still very few implementations of
Unicode. Now, with the web and most of the computing architecture based
on or dependent on Unicode in one way or another, the wiggle-room for
making changes has decreased considerably. This is recognized by the
addition of a number of stability policies and other invariants for the
standard.
A./
PS: Note that all stability policies each come with an "applicable
version" designating from when they hold. See
http://www.unicode.org/standard/stability_policy.html
>
> Sinnathurai
>
>
> ----- Original Message ----- From: "Asmus Freytag" <asmusf@ix.netcom.com>
> To: "Keutgen, Walter" <walter.keutgen@be.unisys.com>
> Cc: "Otto Stolz" <Otto.Stolz@uni-konstanz.de>; <unicode@unicode.org>
> Sent: Wednesday, May 24, 2006 7:11 PM
> Subject: Re: apostrophes
>
>
>> On 5/24/2006 9:45 AM, Keutgen, Walter wrote:
>>> Asmus,
>>>
>>> the situation is even worse. My impression is that the German
>>> quotation marks will vary depending on the FONT. I want to write an
>>> answer in this forum, but the more statements I see passing, the
>>> more I realize that this requires a thorough verification of the
>>> whole discussion in this forum and looking at books, as you did.
>>>
>> To be useful, the CLDR requires detailed and in-depth knowledge of
>> the facts, which only research can give you.
>>> The result is that the distinction between glyph and character once
>>> again is not so easy as that and having code points like 'opening
>>> quotation mark' and 'closing quotation mark' is not an option, as
>>> language tagging would be necessary for choosing the actual glyph.
>>> While this is indeed the spirit of UNICODE, my observation, if true,
>>> endangers somehow the CLDR.
>>>
>> This is an oversimplification. Unicode does *not* encode the generic
>> concept of opening and closing inner and outer quotes, but the
>> specific characters that are used in various traditions. The use of
>> left/right in the character names (corresponding to opening/closing
>> in the earlier Unicode 1.0 names) are somewhat unfortunate in this
>> respect. (They are, of course, a side effect of the cultural bias of
>> the initial group of standardizers, but that's not the point here).
>>
>> A font that's imaging the double quote or >> for 2019 is simply
>> non-compliant.
>>
>> Any data captured in CLDR must be in terms of coded characters and
>> sequences.
>>> There seems to be that 'problem' also in CLDR date and number
>>> formats. Whilst I was too late for changing anything, I realized
>>> that in the existing formats there are 'unexplainable' variations
>>> (in several languages visited) with an added space or not. I
>>> believe it is only a FONT effect i.e. the past contributors used
>>> some a proportional, some an even-spaced font. I.e. specially in
>>> Arial which is a rather narrow font, adding a space enhances
>>> readability, whereas in Courier the result looks perhaps ridiculous
>>> to some tastes.
>>>
>> If this is true, it's probably worth looking into.
>> A./
>>>
>>
>>
>>
>>
>>
>
>
>
>
>
>
This archive was generated by hypermail 2.1.5 : Wed May 24 2006 - 18:55:25 CDT