Manuel Mall wrote:
Probably should do hyphenation at the same time as it iterates over Knuth elements in the LineLM and looks pretty 'ugly' as it modifies the Knuth elements retrospectively.
I'm not sure this will pay off. One note in the TeX book about the Knuth paragraph filling algorithm mentions that it called the expensive hyphenation algorithm less often than the naive line filling algorithm (and therefore run faster!).
If we do it in the whitesspace loop we would need a means of adding break opportunities to the data structures at this point. One possible solution would be to simply add a ZWSP char at each normal break opportunity
I'd go for a Java break mark object, just to avoid any confusion.
and a soft hyphen char at every hyphenation point.
This sounds *very* expensive, see above.
The other idea Andreas suggested, that is to give each Inline LM the last and first character of the their preceeding/following LM when constructing the LM from the FO is also worth a look.
Certainly, but it looks somewhat odd to modify semi-high level APIs to cater for a much more low level algorithm. I find access methods more attractive. J.Pietschmann
