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
