After a lot of thinking and experimenting I finally resolved to take up
the idea below again. When I started distinguishing between Positions
that indirectly generate area and those that do not, I was suddenly able
to create a relatively easy and (hopefully) stable machanism to
determine the first and last areas of a LayoutManager. It already works
on my machine for flow, block and block-container (markers6b passes).
Now I'm trying to add marker support for tables which is a bit special
since we don't have the rigid hierarchy of LMs like before. But I'm
pretty sure this is also doable without to much effort.

There's a downside with all this. There was the idea earlier of not
nesting Positions anymore, but with the above approach I need at integer
member variable on Position. That means we'll have to stick with the
nesting if noone comes up with a better idea. The LM only needs two
integers, one determining the first index ever passed through to an
addArea() method and an integer that has the double function of serving
as a running counter of Positions (seeds the Position.setIndex(int)) and
of helping determine if a Position is the last. At least, this way the
nested Position have more of a reason to exist and take up memory.

I think this approach should be pretty stable against the
getChangedKnuthElements() stage, though I could be wrong. This stage is
a topic I'm still not 100% familiar with, yet.

I'll wait a bit before I commit, so you'll have a chance to veto if
anyone sees a serious problem with this. After all, I still have to deal
with markers on tables first.

On 23.05.2005 09:35:48 Jeremias Maerki wrote:
> The other
> (counting Position instances) failed because the element list may be
> modified after the initial generation thus throwing off counters. I
> discarded this mainly because I didn't want to make the code more
> complicated just to get the indices right again.

Jeremias Maerki

Reply via email to