From: Asmus Freytag (firstname.lastname@example.org)
Date: Sat Apr 24 2004 - 21:05:46 EDT
At 05:33 PM 4/24/2004, Ernest Cline wrote:
>There are problems. Suppose, we define a new variation selector that
>will stay with the preceding mark under normalization.
>Now consider what happens when implementations conforming to
>a standard of Unicode that does not know about the new character
>normalizes the sequence BC CM180 CM160 NVS
> BC = Base Character
> CM# = Combining Mark of ccc #
> NVS = New Variation Selector.
>As far as it knows, the new variation selector is an undefined character
>with a ccc of 0, so when normalizing this it will reorder it as:
>BC CM160 CM180 NVS
>Now lets have this "normalized" string be passed on to an
>implementation which knows about this NVS, There were two
>schemes I proposed for implementing this NVS. Both have problems,
>as I will point out below.
No implementation supporting version X can normalize all data
containing characters from a later release. If that was a requirement
we could never add combining characters. What is required is that
all later implementation normalize any data from version X
the same way a version X implementation would have done and to
not change already normalized data. I think it's strictly speaking
the latter aspect that's guaranteed.
>Adding Variation Selectors with non-zero canonical
>combining classes is possible, but I fail to see the benefits
>from adding new Variation Selectors on the SSP outweighing
>the benefits of defining new vowel marks in the Hebrew
>block. It's not as if the Hebrew block does not have the
>space to add additional vowel points, and frankly,
>anything on Plane 0 is likelier to be implemented sooner
>and on a wider set of platforms..
This is the essential argument.
This archive was generated by hypermail 2.1.5 : Sat Apr 24 2004 - 22:01:34 EDT