--- "Peter B. West" <[EMAIL PROTECTED]> wrote: > The set of property values relevant to a > particular FO are > available in a sparse array, accessible by the int > index corresponding > to the Property.
Which source file has the enumerations of the properties--I'd like to see how you listed them. Are you satisfied with those enumerations--anything you would change if you had to do it over? > What happens when > the width is, as > yet, unresolved, because it depends upon the > resolution of the width of > a reference area in the Area Tree? The value is not > undefined, just > unresolved. When the FO Tree interacts with the > Area Tree, the length > will be resolved. But the Area Tree may be re-laid, > in which case the > value will revert to unresolved. > It may be good to create a sample FO document that would exhibit what you're saying above. Hopefully something that shows a important feature that would clearly fail if we don't take into account the Area Tree while resolving properties. That would help clarify things, and we can use it for testing. > > The resolution of properties within the FO Tree has > dependencies on the > resolution of areas in the Area Tree. > Yes, that appears in Section 3.1 of the spec under Conceptual Procedure: "Unless otherwise specified, processing a formatting object creates areas and returns them to its parent to be placed in the area tree....The formatting object supplies parameters to its children based on the traits of areas already in the area tree, possibly including areas generated by the formatting object or its ancestors." Our changes to property resolution will (probably? eventually?) need to take this into account. First thing's first though--I think we need to stop using string constants for properties in HEAD, and move out the property manager references from the renderers and layout (and Area Tree, possibly). Glen __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/
