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"
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
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
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?