On Aug 31, 2006, at 20:59, Jeremias Maerki wrote:

Yeah, it was a lot, wasn't it? :)
Actually, I was preparing the post myself as yours came in, so I decided to c&p it into a reply, since it did seem to address the same basic issue: interaction between line- and page-breaking.

What I can deduct from this is that my suspicion is probably correct
that implementating hyphenation-keep will be quite tricky with the
current code. I assume we have to do a few changes to make page- und
line-breaking interact more closely (for "changing available IPD" etc.).

Looking closer at hyphenation-keep: this indeed seems very tricky in the current situation.

I got the idea while debugging the behavior when processing the disabled testcase 'page-breaking_4.xml'. Notice that the FlowLM's getNextKnuthElements() is currently only called once, which triggers line-breaking for the entire page- sequence given a LayoutContext with ipd equal to that of the first page's region-body. The second page is only prepared after all line- breaks and the first page-break have been computed.

Note that this results in optimal line-layout for non-paginated media. It would be perfect for an HTML page (or a page with indefinite height) to compute all line-breaks in one go. Given the current page-breaking algorithm, which performs outstandingly, nobody will notice a thing if all pages use the same page-master. From the moment you add a second one with a slightly narrower/wider region- body, you're in trouble, it seems. :/

Taking into account the possibility of varying ipd due to different page-masters or deferred side-floats... this definitely needs to be changed.

As a side-note, looking at memory consumption: it would at least offer a chance to perform cleanup if the algorithm jumps from page- layout to line-layout and back. Looking at computational complexity: it remains a hypothesis FTM, but I'm guessing that in certain areas this may even be reduced by the extra info that would become available to both breaking algorithms if they interact. I haven't looked too closely yet at the current implementation of multi-column layout, but it seems like a mechanism for getting the changed available ipd already exists somehow. How are the line-breaks rearranged/recomputed there precisely?



Reply via email to