Jeremias, I have looked into the problem in more depth. The wrong retrieved marker is not only due to the bogus area, but also to the flawed logic of dealing with retrieve-position for the markers in PageViewport.addMarkers. Even if block 5 adds a bogus area to page 1, block 5 would not qualify for last-ending-within-page.
A correct implementation of the retrieve-position logic requires that the traits is-first and is-last are correctly set. These find a place in BreakPoss, but not all LMs set the traits correctly. A bogus area would again upset the markers, because it would falsely take the trait is-first. If you create markers5c such that block 4 takes two lines (and change the region before to: retrieve-position="first-including-carryover"), you have another failing test case. BPs for bogus areas can be recognized by their position: BP.getPosition().getPosition() == -1. Probably it is a good idea to suppress BPs for bogus areas altogether: if (over && childBreaks.size() == 0) return null. Note that for empty blocks also a BP without areas is returned, with position = -2. I am not sure whether they make sense. They do not generate an area due to a special condition in addAreas. If it is possible to add markers to an empty block, such BPs are necessary, although the position of the markers around a page break is undefined. This is a nasty case: <fo:block><fo:block/>Several lines of text</fo:block> when the text 'Several...' starts on the new page. There would again be an empty area on the previous page. It would again be recognized by !BP.generatesAreas(), but it would again falsely take the trait is-first. 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
