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

From: Andrew West (andrewcwest@gmail.com)
Date: Wed Mar 21 2007 - 04:49:41 CST

  • Next message: vunzndi@vfemail.net: "Re: Comment on PRI 98: IVD Adobe-Japan1 (pt.2)"

    On 21/03/07, Eric Muller <emuller@adobe.com> wrote:
    >
    > In fact, I would guess that if we had had the variation selectors
    > mechanism in place from the start, this mechanism would have been used
    > and the compatibility ideographs would not have been encoded.
    >

    That's an interesting point.

    Take for example the compatability ideographs U+F914, U+F95C and
    U+F9BF, which are all canonically equivalent to U+6A02 and which all
    have exactly the same glyph shape. Would it have been acceptable to
    represent them using variation selectors as 6A02-VS1, 6A02-VS2 and
    6A02-VS3 ? I ask this because the way variation selectors are
    currently defined seems to me to imply that each variation sequence
    for a given base character represents a particular, unique glyph, but
    in this example the three variation sequences would all define exactly
    the same glyph shape.

    Thinking forward to Tangut, there are quite a few characters in the
    Mojikyo Tangut character set (which reflects Li Fanwen's 1997 Tangut
    dictionary) that have exactly the same glyph shape as another
    character in the same character set (but are duplicated because they
    have different readings). It would not be acceptable to encode
    duplicate Tangut characters, but it would be desirable to maintain
    roundtripping to the widely-used (amongst Tangutologists) Mojikyo
    character set. One way to do this would be to define a "Tangut
    Compatibility Ideographs" block, but another way would be to use
    variation sequences. However, I wonder whether it would be acceptable
    to use variation selectors for this purpose, as a particular variation
    sequence would not define the glyph shape of a character but its
    particular semantics.

    Andrew



    This archive was generated by hypermail 2.1.5 : Wed Mar 21 2007 - 04:54:34 CST