On Jun 12, 2006, at 15:29, Simon Pepping wrote:

Hi Simon,

<snip />
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)
org.apache.fop.layoutmgr.PageSequenceLayoutManager.resolveRetrieveMark er(PageSequenceLayoutManager.java:653)
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?

That's a very interesting approach, and may save us some... It could work, provided that, after those nodes are returned, there is either no call to the marker-child's getParent(), or the marker-child's "parent" member is modified (temporarily, as the marker may be retrieved again further on, into a different context).

PropertyParser.parse() returns a Property instance, which may be a LengthBase or subtype. If that is the case, then the LengthBase is instantiated with the original FO as a parameter to its constructor. No matter what we do with the FO --cloning-- or the PropertyList -- unparent/reparent-- afterwards, those LengthBases will refer to another FO instance. If we can make sure somehow that that same FO will be the one for which the LM is created, then the problem would also vanish.

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.

Not all, unfortunately. See the comment in RetrieveMarker about using StaticPropertyList (which stores a reference to its parentPropertyList, which also happens to be a StaticPropertyList etc. until the PropertyList for the fo:root) :/ The preferrable strategy there, I think, is to 'flatten' the tree of PropertyLists, such that a special RetrieveMarkerPropertyList would contain:
a) the explicit properties specified on the RM's parent
b) the inherited properties (preferrably only those with values other than the default)
c) no reference to a parentPropertyList

Same thing BTW for the PropertyLists of fo:table-columns, which we need to keep a reference to for resolving calls to from-table-column(). And to add to all the fun: imagine a fo:block in a marker, with from- table-column() in one of its properties --if the marker is not the descendant of a table-cell, IIC, this would currently throw a ValidationException. But maybe this validation should be performed upon retrieving the marker. If the fo:retrieve-marker is descendant of an fo:table-cell, then from-table-column() would be valid, at least I think so... Can't find any literal references in the Rec. Well, it's exotic, but not unthinkable.



Reply via email to