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 
 > original to be laid-out, so there is no problem leaving the fo:marker 

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 


"Lord, to whom shall we go?"

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to