This code handles finding word boundaries (for double click processing), and finding
points in a range of text where it is safe to word-wrap. This code knows nothing about the UI modules,
and only operates on strings of text (
Though this module contains a few implementations, you probably just want to use the
DOCS SOMEWHAT OBSOLETE - BASED ON ORIGINAL LED CODE.
Word/Row Break/Boundary calculation routines.
Note that because some script systems (notably Japanese) have different notions of "words" for selection (e.g. double-click) and for row (aka line) breaking, we have two correspondingly different notions supported here.
Also - we provide both static routines operating on strings, and routines similarly named, operating on this textstore buffer. The reason for the string-based routines is so that the EXACT same algorithm can be used on text not conveniently (or efficiently) already stored in a TextStore buffer. We provide the TextStore based versions for convenience - it is our main target of these sorts of operations.
One place where the behavior of these routines is not obvious from its name (and so we must nail down by fiat) is what happens when asked to find the word starting from a space character. Do we find the word BEFORE or AFTER the space(s). Or do we condider the string of spaces to be a word? In order to avoid the arbitary choice of selecting the forward or backward word (likely to subtly impact on GUI choices) we instead here return a flag indicating if the word is REAL, or simply a run of spaces. If the caller was looking for a real word and got a run of spaces - he can simply reset the position we were looking from to the END of the run of spaces, or just before it.
For the given text, and offset information, return the next reasonable point in the text to break the row,
for word-wrapping (for example, a space).
Must think a bit about generalizing this for other languages (though it was adequate for SJIS/Japanese, using the Kinsoku rule, but that code no longer exists as part of Led). The basic API will probably persist, but the implemntation will probably need to change significantly.
For the given text, and offset information, return the start and end of the next word. Here word is defined rather losely. In particular, sequences of whitespace are considered a 'word'. In that case, the wordReal value is returned false.
Must think a bit about generalizing this for other languages (though it was adequate for SJIS/Japanese).
NB: textOffsetToStartLookingForWord is zero-based.
No word was found - iff *wordStartResult and *wordEndResult are equal.
*wordStartResult and *wordEndResult are zero-based.
This typedef maps to one of a number of different possible implementations of
TextBreaks abstract class'. When you must construct a textbreaks class - this is
probably what you should use.
Note that it defaults to
The original text break algorithm I had implemented long ago. Its been touched up a bit in Led 3.0 to work better with UNICODE. But its still not up to the 3.0 UNICODE spec - or even very close.
Similar to the behavior you got in Led 2.3 with the old 'qUseSystemWordBreakRoutine' define.
Right now - only implemented for MacOS.