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

Reply via email to