--- Comment #6 from Andreas L. Delmelle <adelme...@apache.org> 2009-03-31
13:48:13 PST ---
For documentation purposes:
Spent quite some time trying to get it working correctly, by deferring the part
after the last page-break in case we have a last page-master and more content
is to follow, but then realized that that approach is suffering the same
deficiency as the implementation as a whole.
By only working with the prepared block-lists/line-boxes, only the page-breaks
not the line-breaks are recomputed.
Checked and verified my suspicion that alternating page-masters with different
column-count don't work either, so this is part of a deeper problem.
My further thoughts can only go in the direction of something similar to
interleaved line- and page-breaking, so a solution for this issue:
a) would solve a lot of other ones as well, but
b) could cause significant overlap with Vincent's long-term objective
A bit more concrete:
LineLayoutManager should be refactored, and line-breaking should probably
modeled along the same lines as page-breaking. See
AbstractBreaker->PageBreaker. Makes you wonder why we don't have a LineBreaker
(yet)? I get the feeling that such refactoring may make it much easier to
restart the line-breaking, using a different reference-ipd. I'm not even sure
we really need a LineLayoutManager to begin with. There is, strictly speaking,
no PageLayoutManager either...
This may cause some other relocations, as I have the distinct impression that
AbstractBreaker is far from 'abstract'. There's too much code in there that
seems quite specific to page- (or block-level) breaking. An AbstractPageBreaker
as a common superclass for BlockContainerBreaker, StaticContentBreaker...?
a) introduce a LineBreaker,
b) expose its 'doLayout()' method,
c) make sure it is associated with the line-boxes
then it should be possible to restart the LineBreaker, during the page-breaking
loop without having to pass via the FlowLayoutManager again.
One suboptimal issue then remains: FlowLayoutManager.getNextKnuthElements()
will not return until a span-change or forced break is signaled. That could
mean we compute line-breaks for 40 pages of content, where maybe the second
page is already different, and 39 pages have to be redone...
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.