I do not have much time to look into your problem, so I will just try
to give a quick answer.

In my view the current BP setup is not able to generate good page
break decisions. It only can do a first-fit algorithm. From your
account, BPs are also overloaded to signal the completion of a page
while they do not really end an area. Your hack is a hack indeed, but
from a quick inspection I would say that it properly marks the
overloaded nature of BPs.

I have written down a proposal for a different strategy of page break
decision. I put my description on the wiki, I believe it serves
two goals:
1. Enabling smarter page break algorithms.
2. Simplifying the addAreas calls, and esp. its iteration over the
collected BPs.

I have not had time to implement this, and therefore also no time to
detect the flaws in my proposal. I would not mind if someone else
would implement it.

Regards, Simon

On Thu, Feb 03, 2005 at 06:19:29PM +0100, Jeremias Maerki wrote:
> Team, 
> I've just checked in markers5a and markers5b which look very closely
> which marker is added to which page for every block.
> As I'm still somewhat in the process of getting to know the layout
> engine I don't have a quick answer to that although I'm making progress
> in understanding. Here's what I found out so far:
> The reason for the bad markers is the addMarkers call, for example in
> BlockLayoutManager.addAreas(). When the LM finds out that the next area
> won't fit on the current page it creates a BreakPoss signalling that
> state. The problem now is that addAreas() also gets these BreakPoss
> instances which aren't visible in the generated document but are still
> generating an (empty) Area (on the page preceeding the one where the
> Area will really come to rest). That causes one marker too many to be
> added to a page.
> The same BTW applies to addID() calls which also remembers IDs on the
> wrong pages.
> What I'm currently doing is trying to really (!) understand the whole
> BreakPoss mechanism so I can figure out a reliable way to find out how
> to avoid this bug. Two possibilities:
> 1. Don't generate bogus areas at all.
> 2. Just suppress addMarkers() and addID().
> I'm currently wondering if the generated BreakPoss instances should get
> an additional flag (or two) which controls the generation of the area
> and the addMarkers()/addID() calls. addMarkers()/addID() may be
> necessary in certain circumstances while on the other side no area is
> generated (empty block with only markers).
> You can easily see these bogus areas when you output to the area tree
> renderer or in build/test-results/layoutengine when running the Ant
> build.
> I'll continue investigating but would appreciate any ideas you might
> have.
> Jeremias Maerki

Simon Pepping
home page:

Reply via email to