--- "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). 


Do you Yahoo!?
Free Pop-Up Blocker - Get it now

Reply via email to