Re: Script variants and compatibility equivalence

From: Asmus Freytag (asmusf@ix.netcom.com)
Date: Sun Jun 06 2004 - 01:59:28 CDT

  • Next message: Mark E. Shoulson: "Re: Revised Phoenician proposal"

    At 10:17 AM 6/5/2004, Peter Kirk wrote:
    >Unicode has defined a mechanism for dealing with the situation, variation
    >selectors. If this mechanism is not appropriate in this particular case,
    >let the UTC come up with another mechanism to meet the user requirement.
    >To define a new set of abstract characters for what are actually glyph
    >variants is to ignore the character-glyph model.

    Variation selectors are a tool.

    They are most useful if some characters of a writing system or notation
    show variations that must be preserved in some contexts, but should be
    ignored in others.

    For the mathematical characters, they reflect the inability to get perfect
    information on whether the shape differences between certain variants of a
    few symbols are semantically meaningful for a few authors. In theory, they
    could have been encoded as characters with compatibility equivalents
    instead, but in the context of how mathematical texts are used, most
    existing compatibility decompositions produce unintended results...

    For the Mongolian characters, they reflect the fact that context analysis
    is not always perfect, but that it is preferable to have base characters
    consistently carry their semantic value only, and no information about
    their positional shape. This makes the model for Mongolian quite a bit more
    regular for many text processes.

    Neither of these cases covers an entire script.

    Unlike you, I see no urgent need for Unicode to invent new mechanisms.

    Implementers will be glad to know that UTC is not contemplating new
    mechanisms either -- new mechanisms tend to have a way of impacting, by
    their mere presence, even implementations that don't want to support them,
    while new characters don't.

    A./



    This archive was generated by hypermail 2.1.5 : Sun Jun 06 2004 - 02:01:15 CDT