Re: Combining Triple Diacritics (N3915) not accepted by UTC #125

From: Kenneth Whistler (kenw@sybase.com)
Date: Tue Dec 21 2010 - 19:14:44 CST

  • Next message: Doug Ewell: "Re: CSUR Proposal: Tonal: U+E9D0 - U+E9EF"

    Michael Everson said:

    > I don't know why people are agonizing about this.

    Because neither Option A nor Option B presented in N3915 represents
    the appropriate, scaleable extension of the requirement to
    use diacritics to span n characters instead of 1 character.

    Both are one-off hacks that break the minute someone comes
    up with another diacritic used this way or extends n from 3 to 4.
    That's why the math formulaic approach works -- because the
    mathematicians from the get go understand about scaling from
    1 to n.

    > There is precedent in a solution for Coptic: COMBINING
    > MACRON LEFT HALF, COMBINING CONJOINING MACRON, and
    > COMBINING MACRON RIGHT HALF.

    And that is a 1980's daisy wheel printer era hack for dealing
    with what is a general problem of placing a mark spanning
    across an indefinitely long segment of text.

    > The same solution is all that is needed for the linguists'
    > tilde and inverted breve. Most likely all we need is a
    > new COMBINING CONJOINING TILDE and COMBINING CONJOINING
    > INVERTED BREVE.

    What are those? They aren't what N3915 asks for.

    > And even in the absence of those, the community could use the
    > relevant halves (which are already encoded) together with
    > the COMBINING CONJOINING MACRON and nobody could stop them.

    Feel free. And likewise nobody can force the developers of
    commercial rendering systems to do anything other than fallback
    rendering for such sequences.
     
    > I would rather see the new COMBINING CONJOINING pieces encoded however.

    What? The seven glyph pieces advocated in "Solution B" in
    N3915 or some others?

    And why would these be desireable, when they would result in
    nothing but a hacked-up representation of the text in question?

    --Ken



    This archive was generated by hypermail 2.1.5 : Tue Dec 21 2010 - 19:18:35 CST