I've got a possible fix for the problem. But I don't know if it's not
too much of a hack. At least it somehow feels like a hack. Any comments
about the attached patch? Obviously, some javadocs are missing and the
naming could probably be improved but this is just an idea how this
could be fixed.

IMO it would be nicer if these "bogus" areas as I call them wouldn't be
constructed at all. I experimented with such an approach but the code
got far too complicated with too much copy/paste/modify. And I also
didn't manage to make it work. On the other side these special areas
are not a big problem since there are relatively few of them.

Still interested in opinions and ideas.... Thanks!

On 03.02.2005 18:19:29 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

Jeremias Maerki

Attachment: MarkerFixProposal.diff.txt
Description: Binary data

Reply via email to