[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fop-dev
Subject:    DO NOT REPLY [Bug 51304] footnotes in multi-column region-body
From:       bugzilla () apache ! org
Date:       2011-07-05 19:03:29
Message-ID: bug-51304-38666-DgXwzVcLsk () https ! issues ! apache ! org/bugzilla/
[Download RAW message or body]

https://issues.apache.org/bugzilla/show_bug.cgi?id=51304

--- Comment #5 from Andreas L. Delmelle <adelmelle@apache.org> 2011-07-05 19:03:29 UTC ---

Update: there was still something lacking in the overall picture as sketched in
the previous comment.
The additional step should actually take the form of a *forced* restart, at the
point of the next unavoidable page-break.

The reason I misread it is that, at first, I overlooked that the algorithm
behaves slightly differently if the available width is such that each break
fits exactly (e.g. 72pt available, and all lines are 12pt --assuming no
stretch/shrink).
As soon as the width is increased or decreased (say to 73, resp. 71pt), there
is a restart on every unavoidable page/column-break. When a line is reached
that would generate overflow, there is a break-plus-restart from the position
after the last line that still fits. In such a scenario, it is conceivable to
alter the mode of the restart, so it jumps back to the last page-break, and
retries the complete page, with a different set of parameters.

If every unavoidable break is 'perfect', however, a restart is never triggered,
and thus it would have to be forced somehow. Given that the cycle is just
node-activation and -deactivation, it likely means overriding deactivateNode()
in PageBreakingAlgorithm. Around every unavoidable break, there is a brief
moment at which there are two active nodes, which then gets reduced to one, so
the outer loop in findBreakingPoints() just continues with the next element.
At the point where a page-break node is being deactivated, there can be a
rather simple check, going back to the first column-break and comparing that
node's totalFootnotes with the footnotes for the node that is about to be
deactivated. 
If they are not equal, it means footnotes were added after the first column.
The next node should then be deactivated as well, so that we end up with 0
active nodes, and a restart is forced higher up. Provided that we then also
properly set the lastTooShort and/or lastDeactivated node(s), the rest of the
solution as sketched earlier should suffice to handle the rest.
I am even thinking that we can already infer at that point whether the last box
with anchors --for the last (set of) footnote(s)-- can still fit with all
footnote content, or whether part of the last footnote needs to be deferred.
Updated patch likely to follow soon.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[prev in list] [next in list] [prev in thread] [next in thread]