Re: Mongolian Rant (was: Biblical Hebrew... was: Tibetan... was: ...)

From: Andrew C. West (
Date: Sun Jun 29 2003 - 11:10:26 EDT

  • Next message: Kent Karlsson: "Soft-dotted (was: RE: Unicode Public Review Issues update)"


    Thank you for your kind response to my latest rant. It has gone a long way to
    reassuring me that my concerns over MFVSs and the already defined Mongolian
    standardized variants are unfounded.

    On Fri, 27 Jun 2003 17:25:50 -0700 (PDT), Kenneth Whistler wrote:

    > The Mongolian variants are normatively defined in tables in both 10646 and in
    > the Unicode Standard, but there is normative, and then there is immutable.
    > Fortunately, the definition of standardized variation sequences is not
    > entangled in any of the stability guarantees for normalization. As far
    > as I know, neither WG2 (in its guiding Principles and Procedures document)
    > nor the Unicode Consortium, at:
    > has made any public guarantee about the immutability of these tables.
    > Of course, there is the general assumption that things that are
    > standardized stay stable, but we are, as Andrew implies, still in
    > early days in terms of understanding all the implications for
    > Mongolian implementations. So enough with the "come hell or high
    > water" rhetoric in this case.

    Sorry, I got carried away (as usual).

    > If it turns out that the actual implementations need to define the variants
    > differently than in the current tables for the MFVS standardized variation
    > sequences, then we just need to define the appropriate technical
    > corrigenda for the standards, and then get on with our lives. In this
    > case, if the only implementations need a revision, then the standard
    > should reflect the consensus practice, rather than vice versa. And in *this*
    > case, there are no stability guarantees (that I know of) standing in
    > the way of fixing the problem.

    That is distinctly not the impression I got from Asmus, but no doubt I got hold
    of the wrong end of the stick.

    > The only barrier is one of getting a sufficiently clear statement of the
    > implementation requirements and a sufficiently detailed specification of
    > the results in front of the committees to enable them to close the loop
    > on this.

    Hopefully the good members of this list who are working on Mongolian shaping
    behaviour will be able to do this.

    > BTW, for what it's worth, I tried arguing a different interpretation of
    > how the MFVS characters had to interact with Mongolian glyph selection
    > than the simple x + MFVS --> fixed glyph interpretation that ended up
    > in the tables, but I personally had neither the intimate knowledge
    > of the Mongolian writing system nor the bandwidth to really make the
    > case. That was a fight for another day.

    Indeed, it has been discovered that there is not a simple one-to-one
    correspondence between MFVSs and variants glyphs, but that in most cases variant
    glyphs will be selected contextually without recourse to any control codes, and
    that MFVSs will normally only be needed to override the default shaping
    behaviour - and also that what variant glyph a particular MFVS selects may vary
    depending upon context.

    > Don't deprecate the MFVSs. Why? Instead, create a technical corrigendum that
    > fixes the table(s) and updates the definition of their semantics
    > until it matches consensus implementation in actual practice.
    > Note that you are a leg up on this already because the MFVS characters
    > are not submerged in the collection of generic variation selectors.
    > They were defined for Mongolian for a reason, and the fact that
    > they are *Mongolian* variation selectors ought to give us some
    > room for making them function as intended for Mongolian.


    > Nobody that I know of is deliberately *trying* to maintain mistakes
    > or unimplementable features in the standard out of some perverse
    > pleasure in frustrating people who are faithfully trying to implement
    > Unicode.

    Glad to hear to hear that.



    This archive was generated by hypermail 2.1.5 : Sun Jun 29 2003 - 11:51:22 EDT