Sadly, that won't work. You'd have to make FOP a two-pass system to use that approach where side regions are layed out in the second pass. With your idea getLastPVWithID() will only result in a correct value after an FO is fully distributed to PageViewports. That would, for example, kill the ability to do out-of-line rendering of pages that can immediately be fully resolved. The approach I'm currently working on takes very little additional processing power and just a little bit more memory per Position instance. Only for special cases additional processing is needed. I'm currently trying to get markers on table-body for which there is no separate LM anymore. Cases like this make the whole thing a little more complicated but there's room for optimization, i.e. the additional processing can be skipped if a table-body has no markers (which is probably a common case anyway).
On 28.05.2005 07:13:20 Glen Mazza wrote: > Jeremias, I think we do something like this for ID's already -- I wonder > if we can use a similar approach here. > > We already have a PSLM.getFirstPVWithID() method, which due to the > (Map/List) data structure that contains this information in > AreaTreeHandler, can probably be easily converted to a > PSLM.getLastPVWithID(). Note that with this method, when we add PV's > having a given ID, we don't bother needing to send "is first" or "is > last" indications, that is easily determinable by the List when it is > complete for that property ID. > > Can we do a similar thing for markers? I.e., feed a data structure > without needing to give first/last indications, and rely on the state of > that structure to subsequently find out what is first/last? > > Thanks, > Glen > > > Jeremias Maerki wrote: > > >As you may have seen I've been working through the layoutengine > >testcases to fix various failures/bugs last week. One of the last > >problems that need to be fixed is markers. Markers already work fine > >under the new page breaking mechanism when an FO is not broken over the > >page/column boundaries. > > > >The problem is getting the two last booleans on getCurrentPV().addMarkers() > >right. Currently the calls are hardcoded to: > >getCurrentPV().addMarkers(markers, true, true, false); > >and > >getCurrentPV().addMarkers(markers, false, false, true); > > > >The isfirst and islast parameters must be set correctly. Currently, I > >don't see a reliable way to determine these values. For example, there's > >some code in AreaAdditionUtils that sets IS_FIRST and IS_LAST flags on > >the layout context but I found this doesn't work reliably. I've > >experimented with two other approaches both of which were not good > >enough. One (flags on Position instances) failed because the first n > >elements at the beginning of the element list may be removed which also > >removed the marker for the first element in the list. 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. > > > >The only thing that sounds like worth pursuing right now is to do > >look-behind and look-ahead in the Position iterator, which is in a way > >extending the approach that is currently visible in AreaAdditionUtils. > >This approach checks whether the current LM changes or not. > > > >Maybe someone has another idea on how to approach this problem. I'll let > >it rest for a moment until I've made keeps and breaks work on tables. > > > >Jeremias Maerki > > > > > > > > Jeremias Maerki
