Grapheme - all-in-one, everything that is not a letter or a number - marks,
punctuations, space, etc.
Word - stop at space, illogical but right because when one wants to word-
wrap (which this is mostly used for I assume) punctuation should be on the
same row which means that a split must happen after the punctuation, e.g.
"hey,<split> joe!"
Sentence - that's very questionable, usually a punctuation (e.g. comma) can
be used to split a sentence into few sentences but that does not mean that
the sentence boundary was found (e.g. full stop, question mark, etc.) in
the current implementation
Line - obviously just line ending, that would be \n for UNIX (x000A in
Unicode) and whatever else someone comes up into his own "standard".
In any case the whole text-boundary finder class looks wrong for any use
case to me, while I was working on KHTML I found that it's much faster and
more reliable to just test if the UChar/QChar is space (via isSpace()) or
whatever the case needs rather then use the finder. I do not want to botch
it out of the toolkit yet but I suppose a class that looks for a QChar
category(ies) would be far more usefull then a boundry type specific to the
boundry finder with assumptions that are not obvious at first glance.
Signed-off-by: Ivailo Monev <xakepa10@laimg.moc>
