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.
Peter
Arved Sandstrom wrote:
> Hi, Karen
>
> OK, if you're going on vacation please don't spend too much time on this. :-)
> Apart from maybe during travel. I can take a look at what is going on too,
> based on your pointers so far. You make it sound fairly simple.
>
> Regards,
> Arved
>
> On Wednesday 25 July 2001 21:18, Karen Lease wrote:
>
>>Hi again Arved,
>>
>>What may make this fairly easy is the fact that the PropertyList object
>>has its own parent reference, to its parent PropertyList. This is set in
>>the constructor for the PropertyList. Except when changing namespaces,
>>it's set to the property list of the FO parent object. Property
>>retrieval is dynamic and will climb the inheritance tree based on the
>>parentProperty value. Unlike the FO tree, the parent PropertyList
>>doesn't reference its children; there are only upwards pointers. So I
>>think if we just add a method to "reparent" the property list that might
>>do the trick.
>>
>>Things to watch out for:
>>use of methods like "from-parent()" in the property values, since these
>>are currently interpreted during PropertyList construction and not
>>during layout. Of course we might just say it's common sense not to use
>>those... at least for now.
>>
>>The other thing we'd have to do is flush the PropertyManager cache for
>>things like font-state. The PropertyList itself (or rather the Property
>>objects it holds) don't generally cache the results of requests (for
>>example, storing an inherited value directly), but the PropertyManager
>>does. Also the use of percentage values in properties causes them to be
>>interpreted during layout, and those "resolved" values are then stored
>>in the actual Property objects.
>>
>>That's about where I'm at right now. I'm going on vacation so I probably
>>won't be as active for the next few weeks, though I will probably
>>continue to mull over various things. On the other hand, tomorrow I have
>>a lot of travel time, so maybe I'll be able to poke at this Property
>>stuff and give you actual code instead of just advice!
>>
>>Best regards,
>>Karen
>>
>>Arved Sandstrom wrote:
>>
>>>If you run some examples, you'll see that where
>>>fo:marker/fo:retrieve-marker currently is incorrect is that the
>>>properties on fo:marker are inherited from the original parent, not from
>>>the parent in the fo:static-content once the marker has been retrieved.
>>>In effect, markers are re-useable (I already have to reset them before
>>>each layout), and they have to be able to dynamically re-parent, sort of
>>>having a static parent for the purposes of retrieval, and a dynamic or
>>>_effective_ parent for the purposes of layout.
>>>
>>>It is easy enough to figure out what the effective parent for layout is;
>>>my question is, since you are the properties guru, what is the most
>>>effective mechanism for re-initiating inheritance using this effective
>>>parent? This would have to be done every time a marker is used. I could
>>>work it out eventually, but I'm lazy. :-)
>>>
>>>Thanks. Arved.
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>For additional commands, email: [EMAIL PROTECTED]
>>
>
--
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]
