Glen Mazza wrote:
--- "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?


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, 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?

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 B. West <>

Reply via email to