Peter B. West wrote: > Property processing is a bit of a quagmire. I have just had a look at > the alt.design documentation, thinking I had detailed the data > structures in more detail than is actually the case. Some of the code > examples are broken at the moment, but the basis of the design for > parsing and representing properties is detailed there. > > 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. > > 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.
Peter: I'm going to move this over to fop-dev & respond there. Victor Mote --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
