Re: Control picture glyphs

From: Asmus Freytag (
Date: Wed Aug 29 2007 - 17:08:40 CDT

  • Next message: Magda Danish (Unicode): "31st Internationalization & Unicode Conference - Early-bird Registration Deadline is September 5"

    On 8/29/2007 2:20 PM, James Kass wrote:
    > Asmus Freytag wrote,
    >> There's no way the
    >> application writer can rely on the font in that situation, short of
    >> there being an additional agreement with *all* font vendors what a
    >> "perfectly good" glyph is.
    > Generally, the application is *required* to use a glyph from the
    > selected font, if the selected font has a glyph mapped with the
    > character being called. The application must rely on the font --
    > that's what fonts are for.
    That's actually not the reality. And where application vendors have
    deviated from that precept, it has often been done for good and solid
    usability reasons - not the least of which is to work around
    inconsistent implementations by fonts.

    The vast majority of text handled on computers is not concerned with
    fine typographical detail but with easy and problem free access to text
    on screen.
    > Asmus is correct, though, in this section. Applications can substitute pictures in lieu of font-specific control picture character glyphs. The choice is best left to the application designer. (T.U.S. 5.0 p. 508 for more detail.)
    And the depiction of an unsupported VS falls into that realm; whether
    the authors of TUS have managed to get around to spell that out or not
    is immaterial.
    >> We disagree about what is desirable behavior on fundamental level, I believe, so it's not useful for me to comment on the remainder of your message.
    > It can often be useful to identify points of divergence. It can help promote better understanding of two sides of an issue, for one thing.
    > I wonder if we differ in the value we place on the importance of
    > authorial intent.
    If an author inserts a VS, the way the standard conceptualizes this, is
    that he's *enabling* supporting implementations to show the difference.
    If the difference is unsupported, it is *supposed* to be ignored (in the
    ordinary case).

    Therefore, the use of a VS expresses the authorial intent this way: "I'd
    rather show this mathematical character with the other style of
    negation, that the default, because I think it's clearer (or whatever).
    So if your font can show this, here's a VS so it triggers the correct
    glyph - but if your don't have the font, you'll still be able to read my
    paper - it just won't show my preferred rendition of these characters".

    The intent is NOT to start putting ugly symbols in the display of any
    and all implementations that don't happen to support the VS sequence.
    Such behavior is completely beyond the pale as far as the *reader* of
    the text is concerned.

    In and *editing* environment, e.g. a math editor, having a limited show
    hidden mode that just reveals the VS, or just reveals any unsupported VS
    characters would possibly be helpful - it allows the author to clean up
    redundant and incorrect VS usage. (But a squiggly colored underline is
    an equally appropriate method to show such keyboarding errors, and right
    clicking could be used to initiate and automatic cleanup. The same
    method could be used for redundant ZW(n)J, doubled SHY characters,
    etc.). But this is the machine communicating with the *author*, which
    serves a different set of requiremens than the machine transporting the
    intent of the author to the reader.

    The design of the VS is predicated on that it expresses *ignorable*
    differences. Therefore, forcing it to become visible to all readers, by
    default, is missing the point entirely. This is true whether it's an
    unsupported one or and undefined sequence. Again, the only exceptions
    are the show hidden modes, which provide a meta-view of the text.


    This archive was generated by hypermail 2.1.5 : Wed Aug 29 2007 - 17:10:48 CDT