RE: New FAQ page

From: Philippe Verdy (verdy_p@wanadoo.fr)
Date: Fri Oct 12 2007 - 17:35:43 CDT

  • Next message: Doug Ewell: "Re: New FAQ page"

    James Kass wrote:
    > Mark Davis wrote,
    > >Your chart example means absolutely zilch.
    >
    > Chart example? What chart example? I suppose you mean the
    > character map application example in which "zilch" is that
    > which is gained.

    The chart examples (including the charts in the Unicode standard) are not
    plain text, simply because of their layout required to make them legible.
    Don't assume that what the chart displays being meaningful in plaintext.
    What is displayed in that case is not representative of the glyphs that will
    be used in actual texts, just focusing what is the intended meaning so that
    each cell can be distinguished.

    Even if an application needs some font support to exhibit such VS boxes, it
    is not required for fonts normally used to render plain text. Fonts and text
    renderers are first built to display plain text correctly, you can do
    whatever you want to display other things such as specific VS boxes for
    building font charts, failing to display VS sequences as intended for plain
    text will miss the point.

    So BEFORE building some support for custom boxes (which is an optional
    possibility) don't forget to support FIRST the standard behaviour which
    should be the default behaviour of your rendering system. To display custom
    glyphs make them available only in specific modes when they are specified by
    the application needing it.

    Notably, VS characters have NO standard behaviour in plaintext when they
    don't follow one of the characters for which there's a defined sequence
    defined in the standard. So when VS characters are appearing isolately, they
    are creating DEFECTIVE sequences: that the place where your renderer could
    display a specific visible glyph, and that will allow you to build charts,
    and even to allow atext editor to work in "visible controls" mode (but such
    editor will use a "feature" in fonts or in renderer to disable explicitly
    the standard behaviour.

    Soyes, I agree with Kenneth and others when they want invisible VS because
    this is the way they were created since the beginning. Any attempt to change
    this would change the VS characters into symbols (that may be part of some
    ligatures), and would defeat the standard. VS characters are NOT spacing
    symbols, they are even not combining characters.

    One of the best way a font can view VS characters is as zero-width spaces
    that may offer some ligatures for those VS sequences that are defined in the
    standard. For every othercase, they remain invisible (that's why their
    code-to-glyph binding in fonts should be to a zero width invisible glyph by
    default, and a specific feature, disabled by default, should encode all
    other bindings to visible glyphs; the standard only permits binding by
    default some sequences of a character followed by a VS, every other
    sequences should be disabled by default).



    This archive was generated by hypermail 2.1.5 : Fri Oct 12 2007 - 17:38:39 CDT