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