Jeremias, 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, http://wiki.apache.org/xmlgraphics-fop/PageLayout. 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: http://www.leverkruid.nl
