--- "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?
fo.PropertyNames
No, I'm still happy with this. Note that there is one property which no longer exists. I can't remember which, off hand. The editors created it in response to one of Karen's typically incisive questions, and I added it. Months later, they came back with a different response, scrapping the new property and clarifying the behaviour of related pre-existing properties.
Note also that there is no such thing as a compound property. The editors were suffering from OO fever, compounded by CSS2 compatibility-itis (a disease which afflicted the Recommendation in a number of places.)
I treat compounds as a special case of shorthands.
Note also that alt.design, as yet, has no corresponding property handling, but corresponding properties must be defined in a particular way in the list of properties.
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?)
definitely, absolutely
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).
As I've said before, we've tried the "first things first" approach before - it's called FOP 0.*.*. FOP 1.0 *must* be so designed that it can be fully conformant, even if it isn't in the first releases. We cannot get into a position where another redesign is needed to get to conformance.
Peter -- Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>
