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.


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:

Jeremias Maerki

Reply via email to