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

From: Kent Karlsson (
Date: Fri Aug 08 2003 - 07:42:46 EDT

  • Next message: Janusz S. Bień: "Re: UTF-8 and HTML import into MS Word 2000"

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

    Yes, sorry.

    > "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,


    The insertion of ANY formatting (or other control) character
    causes a "positional separation" (in that they break the combining
    sequence, if inserted into one)!

    > 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.

    Now are many formatting (or other control) characters suddenly
    *effectively* allowed INSIDE combining sequences via some hitherto
    well hidden back door?! I do hope not! But if they are, they should be
    *explicitly* allowed (I think allowing that would be a very bad idea,
    however). It's not the case now, see TUS3, D17a, which (correctly)
    says nothing about "causing positional separation" (whatever that
    would be).

            /kent k

    > 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 : Fri Aug 08 2003 - 08:33:37 EDT