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]
