RE: Questions on ZWNBS - for line initial holam plus alef

From: Kenneth Whistler (kenw@sybase.com)
Date: Thu Aug 07 2003 - 19:49:00 EDT

  • Next message: Kenneth Whistler: "Re: Questions on ZWNBS - for line initial holam plus alef"

    Kent said:

    > >
    > > How is: <a, ring above, null, dot below> supposed to be different from
    > > <a, dot below, null, ring above>
    >
    > The first would be an å followed by separate dot below (under a space,
    > according to p. 131 of TUS 3.0). The second one is an <a, dot below>
    > with a separate ring above (over a space according to TUS 3.0 p. 131).

    Dunno what you are talking about. TUS 3.0 p. 131 is part of the
    table of line boundary rules, and has nothing to do with this
    display issue.

    I suspect this was a typo for p. 1*2*1, where you find the sentence:

    "Defective combining character sequences should be rendered as if they
    had a space as a base character."

    But if that is your intent, then you have to take that in the
    context of the beginning of the paragraph as well, which starts:

    "In a degenerate case, a nonspacing mark occurs as the first character
    in the text or is separated from its base character by a line
    separator, paragraph separator, or other formatting character
    that causes a positional separation. ..."
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

    In the case I have cited above, insertion of a null is not an
    instance of an insertion of a formatting character that causes
    a positional separation, and you are right back to the kind of
    rendering conundrum as I originally stated it: does the renderer
    focus on the defectiveness of the combining sequence and separate
    off the second combining mark (as you suggest) or does it
    focus on the ignorability of the inserted character and
    render the entire sequence, ignoring any display effect of the
    inserted ignorable character.

    I don't believe that your assertion about how that sequence
    "would" be rendered can be taken as a mandate by the standard,
    at all.

    --Ken



    This archive was generated by hypermail 2.1.5 : Thu Aug 07 2003 - 20:27:55 EDT