On Saturday 30 December 2006 21:50, J.Pietschmann wrote:
> 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!).
>
Joerg,

not sure this applies to fop. Seems to me, after a cursory code 
inspection, that we always call the hyphenation function during 
linebreaking (if hyphenation is enabled). Therefore doing it under the 
same circumstances earlier should not add any overheads. May be someone 
with a better understanding than me on the hyphenation subject can 
clarify that.

> > 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.

Yes that's clearly the cleaner solution - it just affects so many 
internal interfaces though.

>
>> and a soft hyphen char at every hyphenation point.
>> This sounds *very* expensive, see above.
>

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.
>

Not sure what to make of this comment. I agree in principle but have 
problems applying it to the situation at hand. If I knew how to easily 
build these access methods then I would not have started this whole 
discussion.

> J.Pietschmann

Manuel

Reply via email to