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
