Arved Sandstrom wrote:
At 01:46 AM 7/28/01 +1000, Peter B. West wrote:
Arved Karen,
On the surface of it, this re-parenting issue looks like a tree
operation. The point of definition of the marker remains in its context
at the point of definition. When a retrieve-marker is found, the marker
sub-tree is attached as a child of the retrieve-marker. As long as
there is a check for cycles, there s no reason that a sub-tree cannot be
attached at multiple points in the tree. There are probably a few
complications in terms of removal, but I have yet to work through all of
these issues anyway.
In fact, you're right, this would be much better. Rather than change the
parent of the original, just create a temporary copy that gets
attached as a
child of the fo:retrieve-marker. Because the original should stay
where it
is for future marker operations. In any case the code does not permit
the
original to be laid-out, so there is no problem leaving the fo:marker
there.
It shouldn't even have to be a temporary copy. Because [t]he
fo:retrieve-marker does not directly generate any area. It is
(conceptually) replaced by the children of the fo:marker that it
retrieves and because fo:retrieve-marker may have no other children,
the appropriate fo:marker subtree can be added as a child of
fo:retrieve-marker and left there. Formatting of fo:retrieve-marker
could then proceed as for any other subtree. Well, it sounds good in
theory.
Peter
--
Peter B. West [EMAIL PROTECTED] http://powerup.com.au/~pbwest
Lord, to whom shall we go?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
