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
