Re: Comment on PRI 98: IVD Adobe-Japan1 (pt.2)

From: Richard Wordingham (richard.wordingham@ntlworld.com)
Date: Mon Mar 26 2007 - 17:58:42 CST

  • Next message: Asmus Freytag: "Unicode Thank You at WG2"

    Philippe Verdy wrote on Monday, March 26, 2007 1:37 PM
    Subject: RE: Comment on PRI 98: IVD Adobe-Japan1 (pt.2)

    > Andrew West wroite:
    >> If, for example, I were to write a text editor that allowed the user
    >> to perform various transformations to a text (e.g. casing, diacritic
    >> folding, normalization, transliteration conversions, etc.), there is
    >> nothing that Unicode could say or do to stop me from also adding in a
    >> facility to convert between CJK Compatibility Ideographs and their
    >> corresponding CJK Unified Ideograph plus IVS if I so desired.

    If this process satisfied the conformance requirement of canonically
    equivalent inputs yielding canoncially equivalent outputs, you would have to
    append the same variation selector to a compatibility ideograph and its
    corresponding unified ideograph.

    > What you are doing is not implying automatically such preservation of
    > canonical equivalence of the output; it may be true if your implementation
    > respects the contract, but your description could correspond to the
    > following description, which is NOT a conforming process:
    > * change a CJK Compatibility Ideograph to its corresponding CJK Unified
    > Ideograph plus IVS;
    > * change a CJK Unified Ideograph plus IVS to the next higher CJK Unified
    > Ideograph plus IVS, if there's one, or to the CJK Compatibility Ideograph;
    > * keep the other characters unchanged;

    > Apparently it seems conforming, but consider the case where there are
    > diacritics within or just after the sub-sequences being modified; and
    > consider how default grapheme clusters are delimited.

    Could you please give an example. Variation selectors are non-spacing
    marks, so I don't see how the default grapheme cluster boundaries are
    affected.

    Richard.



    This archive was generated by hypermail 2.1.5 : Mon Mar 26 2007 - 18:01:23 CST