On Thu, Jun 08, 2006 at 02:30:09PM +0200, Andreas L Delmelle wrote:
> On Jun 7, 2006, at 20:46, Andreas L Delmelle wrote:
>
> ><snip />
> >And so I did... Guess what: there seems to be an inherent error in
> >the marker descendant re-parenting process. It must have been there
> >for quite a while. Nobody ever noticed. :)
> >Some debugging showed that the clones of the marker descendants
> >have a RetrieveMarker as a parent (instead of the parent of the
> >RetrieveMarker as prescribed by the Rec)
> >
> >So, good news: Should be easy to fix, and the percentage resolution
> >should work like a charm. :)
>
> Looking closer, this error does have its reasons it seems...
>
> RetrieveMarkers are resolved in the parent's createChildLMs(), in
> iterating over the list of childNodes. Subsequently, the
> RetrieveMarker is unable to reparent the cloned subtree to its own
> parent, since this would lead to a ConcurrentModificationException...
>
> It's probably going to be easier to get the percentage resolution to
> point to the RetrieveMarker's parent in case it encounters a
> RetrieveMarker.
I wrote some of this code over 1 1/2 years ago. Apparently I had the
wrong impression that the marker subtree could be attached to the
retrieve marker.
Would it not be the best solution in this stack:
at
org.apache.fop.fo.flow.RetrieveMarker.cloneFromMarker(RetrieveMarker.java:163)
at
org.apache.fop.fo.flow.RetrieveMarker.bindMarker(RetrieveMarker.java:214)
at
org.apache.fop.layoutmgr.PageSequenceLayoutManager.resolveRetrieveMarker(PageSequenceLayoutManager.java:653)
at
org.apache.fop.layoutmgr.AbstractLayoutManager.createChildLMs(AbstractLayoutManager.java:247)
to let RetrieveMarker.cloneFromMarker return the Marker's children,
the same for RetrieveMarker.bindMarker and
PageSequenceLayoutManager.resolveRetrieveMarker, so that
AbstractLayoutManager.createChildLMs can add them as if they were its
own children?
There may be problems with the property lists of the Marker children,
which are currently not cloned, but referred to in descPlists. The
property lists of a subtree of a marker are special, because they must
be kept alive for later retrieval. Other property lists are garbage
collected after the properties have been bound to the LM and the
subtree of the FO has been processed. Maybe it is best to just copy
the property lists of the marker subtree. The copies will be garbage
collected in the normal way.
I have no time to try this solution myself.
Simon
>
> Later,
>
> Andreas
>
--
Simon Pepping
home page: http://www.leverkruid.eu
