On 01.09.2006 01:21:22 Andreas L Delmelle wrote: > 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.
Doesn't sound like total-fit anymore, more like best-fit. Vincent and Simon said total-fit for page breaking is very important. > 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. :/ Yep, that's one of the current problems. > 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? Available IPD can currently only change if you have a force page break. Here the page breaking process restarts. Line-breaks are not recomputed AFAIK. Otherwise, I'd be much happier. The only elements we currently have for multi-column layout are: * Column balancing logic * Span-change logic (page breaking is interrupted on a span-change, different block sequence) Otherwise, a column is just like any other page with only one column. That's why we can't do keep.within-page, yet. Jeremias Maerki
