The problem is (again) that the breaking text into lines and words logic
crosses inline boundaries and our nested inline processing is getting really in
the way. To get around this the code has to 'jump through hoops'. In this case
the Knuth sequences returned by getNextKnuthElement are used to reverse
engineer words which extend over an inline boundary. This in turn needs to be
done to determine if an additional letter space needs to be added as the
individual LMs don't do that at a boundary because they don't know if they
start/end at the beginning/end of a word or in the middle of a word.
Of course this "ranting" about the problem will not get us a solution. In the
very short term may be Luca can have a look at this as he as fixed a similar
problem before in a related area.
After that we really need to redesign the line breaking stuff. Not the Knuth
approach (and the implemented algorithms related to that) but the way we arrive
at the Knuth sequences and iterate and process the text elements. This needs to
be done to be able to do white-space-treatment, UAX#14 line breaking, start-
/end- space resolution and generally to be able to handle some more aspects of
Unicode (e.g. glyph merging).