From: Asmus Freytag (
Date: Tue Aug 11 2009 - 12:33:30 CDT

  • Next message: Andreas Stötzner: "Greek characters in IPA usage"

    On 8/11/2009 1:44 AM, James Cloos wrote:
    >>>>>> "Asmus" == Asmus Freytag <> writes:
    > Asmus> adding the VS to the mix changes less than you might think.
    > It wasn't my proposal, just my reading of the suggestion made on the
    > list in reply to the original post.
    António started the ball rolling with this notice:
    > At < >, a
    > new symbol for JIS is shown and discussed. Will there be a new
    > character in the Standard? (Not a new glyph in the same codepoint, I
    > hope!!)
    Doug joined in:

    > If this is a character, those should be glyph variants.
    Peter was skeptical that anything would be encoded:

    > The only plausible reason for a new character would be to provide compatibility with a Japanese encoding standard in which two different JIS symbols were encoded. That's a minimal criterion, and it seems very unlikely to me that it would be realized. So, a glyph variant seems the only option for someone who really needs to encode and display the new JIS logo.
    which leaves open of whether he means just providing fonts with a new
    glyph or coding a standardized variant.

    After which I provided an actual analysis of the various options.

    > I was just curious which of our interpretations matched what that author
    > actually meant. (As you might guess, I've not search through the archives
    > to remind myself who wrote it; I jsut remembered reading it and concluding
    > that the suggestion was to use VS1....)
    If you do that, you can see, you are the first one to call this a
    "proposal" and to supply the sequence:

    > I read the earlier post as suggesting that <U+3004><U+FE00> should be
    > used to specify the new glyph.
    This just underscores my point: somebody sends an informative post
    explicitly indicating that treating it as a glyph variant would be
    undesirable, and before you know it, out comes the VS1 :)

    Variation selectors were intended as *exceptional* mechanism to deal
    with certain difficult edge-cases where the character vs. glyph question
    is undecidable. To qualify as a standardized variant an entity must
    clearly be the *same* character, in most cases. That means, in most
    contexts, substituting the base character is not only harmless to the
    meaning of the text, but ideally not even noticeable by many readers.
    (That is true, basically, for both standardized and regular glyph
    variations, such as those you achieve by switching fonts). There's a
    second requirement for standardized variants, namely that there must be
    some contexts where the glyph choice is expected to matter, but that
    this requirement applies in a very restricted way, so that it is
    insufficient to cause disunification.

    The two glyphs for 'a' or for 'g' are distinct only in IPA, but in that
    context, the distinction is important enough to require distinct
    characters, because accidentally substituting one for the other would
    destroy the meaning of the IPA text.

    The two glyphs for GREATER-THAN BUT NOT EQUAL TO "may" be distinct
    (nobody knows for sure) in some contexts (they are distinct in some
    entity sets), but the mathematical meaning of the text is unaltered. A
    standardized variant allows the preservation of existing data, or choice
    of one form over the other, without requiring duplication of characters.

     From that you can see that a VS should never be considered a mechanism
    to simply organize a bunch of "similar looking" glyphs under a common
    character code. The term for that kind of usage is "pseudo-coding", and
    it "should be considered harmful".

    Harmful enough that it's useful to discuss why such a thing is
    inappropriate at the first mention of "encoding" & "glyph variant".


    PS: in the case of U+3004, the best thing would be to see the new logo
    remain unencoded (and open to use as PUA character as are all the other

    This archive was generated by hypermail 2.1.5 : Tue Aug 11 2009 - 12:37:39 CDT