Simon, thanks for looking into this. I'm not quite sure I got your instructions for a "markers5c" right. I'd appreciate if you'd check in the test case you created.
I've added a Bugzilla item [1] for this. I intend to revisit this later. It would really be good to have test cases for all those nasty effects. If you find anything wrong (not just fpr markers) PLEASE write a test case and check it in even if it doesn't work ATM and you have to add it to the disabled-testcases.txt. You don't have to write the XPath checks yourself. We can always do that later. [1] http://issues.apache.org/bugzilla/show_bug.cgi?id=33555 On 13.02.2005 12:26:27 Simon Pepping wrote: > 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 Jeremias Maerki
