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)
at
org.apache.fop.layoutmgr.PageSequenceLayoutManager.resolveRetrieveMark
er(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?
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.
Later,
Andreas
