Re: New FAQ page

From: James Kass (thunder-bird@earthlink.net)
Date: Fri Oct 12 2007 - 02:43:09 CDT

  • Next message: James Kass: "Re: New FAQ page"

    Mark Davis wrote,

    >> ... Display issues such as these are beyond the scope of a
    >> character encoding standard. Suggestions are fine, defining expected
    >> behavior is not.
    >
    >The VS characters represent a mechanism that has been defined by the Unicode
    >standard -- it is not as if these existed before the standard created them!

    So far, so good.

    >And their defined appearance is as invisible and nonspacing if they are not
    >part of a standardized sequence; and if they are part of a standardized
    >sequence then their effect is to change the appearance of the previous
    >character.

    VS characters are peculiar beasts. They behave like combining characters.
    Other combining characters may be displayed in isolation in various
    sanctioned ways. VS characters should be displayable in isolation, too.
    The advantages of the ability to display such characters in isolation
    should be obvious.

    We disagree on whether it's Unicode's business to determine how any
    given character is displayed. Assuming for the sake of discussion that
    it *is* Unicode's business, what would be required to get that definition
    changed?

    That definition makes no allowances for specialty fonts such as the one
    shown in the graphic attached to a recent post. One of the fonts used
    in the graphic displays the hex value of most non-ASCII BMP characters.
    This will only work as long as the system renders text as it currently
    does, with no arbitrary strictures.

    Further, that definition forbids the currently functioning ability to
    visually indicate a bad VS sequence. Suppose some of us consider that
    ability a Good Thing?

    >So as said before, for normal usage, your first line is not correct. It is
    >just as wrong as if you showed all the spaces in that line as being boxes
    >with SP in them.

    If you have selected a display font which maps a box glyph to U+0020,
    then your system will display boxes instead of spaces. That's expected.
    To make the boxes go away, select a different font.

    If "A" is just as wrong as "B", and "B" is right, what's wrong with "A"?

    >Of course, in special modes like Show Hidden you might show both spaces as
    >boxes with SP in them (or using other conventions -- the standard doesn't
    >restrict you there) and VS1 as you show above. But what you do show is
    >simply not the desired appearance.

    Desirability is subjective.

    > ...
    >There are a great many issues about font design that are outside of the
    >scope of the standard. But there are certain ones that *are* in the scope,
    >namely those dealing with mechanisms architected by the standard, or having
    >to do with the fundamental identity of characters.

    A plain text computer character encoding standard should define
    plain text and characters. The standard should determine which
    symbols are suitable as characters and assign unique binary strings
    to same for purposes of computer storage and computer exchange.
    The standard may assign properties to characters to assist in text
    processing.

    Determining which characters to display and how they will be
    displayed seems out-of-bounds here. I perceive this as an attempt
    to "step on" the artistic and conceptual decision-making rights of
    font developers and rendering engine architects.

    Best regards,

    James Kass



    This archive was generated by hypermail 2.1.5 : Fri Oct 12 2007 - 02:47:24 CDT