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





--- Comment #14 from Andreas L. Delmelle <[email protected]>  2009-04-15 
10:53:16 PST ---
(In reply to comment #11)

Hi Vincent

My next attempt would probably go in that direction. If you look at what
BlockContainerBreaker does, for example, this gives a clue as to how it might
be solvable (but that's still a vague idea in my head). That breaker
implementation explicitly performs the layout but skips area-addition, and
keeps the algorithm suspended after phase 2, until it is called upon by the
parent LM (see: addContainedAreas()).

The only thing that's still a bit puzzling is the case of multiple span-changes
on the last page. 

So, we need to defer the area addition until the last part is reached. 
Actually, a bit more correct:
- first we need to add the areas for the first part (else the following part
will not get the correct available BPD)
- then, if the following part produces only one page, we know that both parts
fit on one page, and we somehow need to keep a reference to the areas

This will have to be taken into account every time the FlowLM returns for a
span-change. The first parts can only safely be let go if the last part
produces more than one page. Only one page for the last part means all the
parts will fit together on one page, which will then also be the last (or
only).

With this, the difficulty rises of determining when we reach the last page
condition. Currently, this means 'if the FlowLM is finished'. 
Since we would add a scenario of multiple parts being deferred to the last
page, this no longer seems to suffice, so we'll need to come up with another
way to check this condition.

At any rate, one lesson learnt: teaching AbstractBreaker to deal with a
sequence of BlockSequences (instead of one BlockSequence at a time) including
span-changes, does not seem doable. Maybe we'd better remove that intermediary
blockLists member then, instead of pretending to loop over it... ;-)

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Reply via email to