Re: Variation selectors and vowel marks

From: Asmus Freytag (asmusf@ix.netcom.com)
Date: Sat Apr 24 2004 - 21:05:46 EDT

  • Next message: Michael Everson: "Re: Standardize TimeZone ID"

    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.

    A./



    This archive was generated by hypermail 2.1.5 : Sat Apr 24 2004 - 22:01:34 EDT