--- Comment #7 from Vincent Hennebert <vhenneb...@gmail.com> 2009-04-01
03:30:29 PST ---
I'd suggest you not to worry about changes in the number of columns, otherwise
you will indeed bump into the very problems that I am trying to solve at the
moment. It's a known limitation that FOP can't handle pages of different widths
at the moment, and changes in the number of columns are basically that:
different line widths.
Your idea of deferring the calls to addAreas looks promising to me, I think you
should pursue in that direction and that may be enough for now. Also, in the
sample file the dimensions of the region-body for the last page (PageBack) are
the same as for the other pages (PageFront). I've seen a lot of documents for
which that was the case, and the only difference was in the static-contents for
the page header/footer. It may be worthwhile to check the dimensions of the
last page, and if they are the same there's no need to re-do page breaking at
all. Or even, if the bpd of the last page is smaller than on other pages but
big enough to receive the content for the last part, then no need to re-do page
breaking either. That would also solve the column-balancing problem.
(In reply to comment #6)
> For documentation purposes:
> Spent quite some time trying to get it working correctly, by deferring the
> 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
> as a common superclass for BlockContainerBreaker, StaticContentBreaker...?
> If we:
> 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
> 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.