I was aware that there should not be a line break or word break between the space and the NSM, although I suspect that many implementers will not be aware of this, or at least will not test for it properly and so treat any space as a word break and a line break opportunity. As I just wrote, this requirement to test all spaces for following NSMs is a significant inefficiency built into the standard.Some of this seems to be in reference to an earlier contention that Text Boundaries (inc. Lines) break between the space and the non-spacing mark. I think this was attributed to Phillipe.
[This may not be true: I don't actually read his email, because the information content per line falls below my email threshold; not to say that there may not be information there, but I cannot afford to take the time to find out -- sadly, one of my character flaws.]
All of the text boundaries preserve grapheme cluster boundaries, which never separate a base character (including space and NBSP) from a following NSM. In addition, each of the boundary types above grapheme clusters make some statement about the behavior of the grapheme cluster. For example, with line boundaries a SPACE + NSM has a special behavior. With the others, the behavior is the same as the base character.
As Ken points out, in any event these are default boundaries, and can be tailored. That being said, if the normal behavior of the default can be improvied, and someone has a concrete proposal for doing so, then it can be considered.
Mark __________________________________ http://www.macchiato.com ► “Eppur si muove” ◄
But there is still a problem if there is considered by default to be a word break and a line break opportunity AFTER the NSM. I would suggest, as a candidate for a concrete proposal, that the default behaviour be adjusted so that there is no word break or line break opportunity here either.
-- Peter Kirk [EMAIL PROTECTED] (personal) [EMAIL PROTECTED] (work) http://www.qaya.org/
