Peter B. West wrote: [This message was originally on fop-user. I have moved it here as it is mostly a dev topic.]
> The approach I took was to resolve all of the properties at every node > in the tree during the parsing. As the FO tree builder descends to the > leaf nodes, a complete properties array is maintained at each level. > Before the tree builder exits a node though, all properties not relevant > to that particular node type are discarded (i.e. the property sets are > "reduced") so that the maximal data arrays are short-lived. The > relevant properties are maintained in sparse arrays. FWIW, we now have the FO Tree tied together in a more tree-like way. We have several methods which rely on going up the tree to an appropriate level to get information. Right now, that is mostly high-level stuff like the logger & document-level information. For properties, I recommend that we use appropriately-named "get" methods for each individual property. Then we can hide the data structures behind that & modify them as needed. So if a "get" method sees that the property is inherited, it can get it from the parent node instead of needing to walk through the tree to resolve the value. > There is a flaw in this approach which is exposed when markers are > processed. Because marker subtrees are conceptually "re-parented" in > the static-content tree of the page on which they are laid out, the > properties within the marker tree cannot initially be resolved, and the > properties of the static-content trees cannot be "reduced". This > situation is not catered for in the existing code, but is quite easy to > accommodate by not reducing the property sets of nodes in the > static-content, and by slicing the marker subtrees out and storing them > unresolved for later processing, including property resolution, in the > context of static-content. > > All of this assumes that property resolution cannot be completed > independently of layout. This is a major point of difference between me > and everyone else on the FOP team, but the implication is there in the > Rec. if you read it carefully. I think I agree with your statement that "property resolution cannot be completed independently of layout" for the specific case that you mention. I think where we differ is about whether the FO Tree can simply store a "To Be Determined At Layout" value and go on about life, or whether the concept of the FO Tree should be scrapped entirely because of this issue. Victor Mote
