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.


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]

Fairly Senior Software Type
e-plicity (http://www.e-plicity.com)
Halifax, Nova Scotia
Wireless * B2B * J2EE * XML

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

Reply via email to