Also, one more point--I think it may be a good idea for us to abstract out AreaTreeModel from PSLM and encapsulate it back into AreaTreeHandler (i.e. RootLayoutManager), including moving resolveRetrieveMarker() there. IIRC I was the guilty party who moved ATM into PSLM to begin with, quite erroneously thinking that ATH might be proven superfluous over time, and so trying to make direct ATM<-->PSLM linkages. ATH is here to stay, though, and resolveRetrieveMarker() is something that cycles through the results of several PSLM instances so it seems more natural/intuitive to have it in the higher, root-level processing class here. Thoughts?

Thanks,
Glen


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





Reply via email to