On Nov 23, 2006, at 12:14, [EMAIL PROTECTED] wrote:

<snip />
An excellent idea. However, before I go any further with implementing
anything I'd like to make sure that I actually understand what's going
on at the moment and (more importantly) what should be going on.

As I understand it, objects in the fo tree describe the structure of the
document and relate directly to the xsl:fo input.

100% correct. I myself am very much in favor of not having an identity relationship between the FOTree and the source document, but already perform some normalizing there (since there are possibly different FO structures, yielding the exact same result), and thus making the layoutengine's job a bit easier.
But OK, that's another story: your base assumption is correct.

All these objects descend from FONode and all have a number of distinct properties which
relate in some way to the input document and which may or may not have
some bearing on the output (e.g. aural and accessibility properties don't
have any impact whilst font and text properties do).

Also correct, and the set of properties for which each FO has members corresponds to the properties that are mentioned as applicable to that type of FO.

All the property
classes are supposed to be immutable even though some of them aren't and
none of them use final members. Is this all correct so far?

True, and this could be much improved, I'd say...

What I'm less clear on is the use of PropertyList and PropertyMaker.

AFAIU, way back when, the situation was far worse than it is now:
Instead of having members for only the applicable properties described in the XSL-FO Rec., each FONode used to have one PropertyList as an instance member. PropertyLists however, require space for *all* possible properties even if they don't directly apply to the FONode (see the implementation of StaticPropertyList which allocates space for two arrays with a number of elements equal to the number of all properties; since about 70%, if not 85%, of those elements will be null anyway, it's a big waste to keep those lists alive much longer than is absolutely necessary). This was changed, and the PropertyList should currently only be available as a temporary window during FOTree building, only used for converting the Attributes into Property objects. In FONode.bind() these properties are transferred to the instance member slots. By the time layout kicks in, ideally, there should be no PropertyLists alive in the FOTree, with the exception of those lists for markers/retrieve- markers (currently the latter also means keeping a reference to parentPropertyLists, so the ideal is not yet reached).

WRT the last remark: possible solution would be to create a PropertyList subtype that is able to collapse the tree of lists -- dump all available properties into its own instance member arrays-- and sever the link to the parentPropertyList.

Some properties such as KeepProperty or EnumProperty have makers
as static inner classes.

That's the general idea. As far as I get the picture, external Makers are used when there is no compelling reason to create a whole new Property subclass (see FontSizePropertyMaker: there is no FontSizeProperty, since the LengthProperty infrastructure suffices for the rest)

Don't know if you've already taken a look at org.apache.fop.fo.FOPropertyMapping. Very helpful class to see how the properties map to the Maker-types.

Some properties such as SpaceProperty have both
an inner static class and an external maker class.

That's a bit of an exception. The external Maker descends from CorrespondingPropertyMaker, and seems to be used only for computing the space-* properties from the corresponding margin-* properties. The internal Maker descends from CompoundPropertyMaker and is responsible for creating the space-* properties themselves (from scratch).

Some properties such
as PercentLength don't seem to have any makers at all. Why?

Good question. Best explanation I can think of is that PercentLength simply relies on LengthProperty.Maker. Apparently, there was no need to override the Maker as well...

It occurs to me that the best strategy for handling these would be to
turn all Makers into singletons and use use them as flyweight factories, introducing a new factory for the Common* property classes. What do you

Seems like a fine idea. The Makers will then become responsible for checking whether an identical Property was already instantiated earlier, and create a new one only if there wasn't. As for the Common* property classes, I guess it would then become possible to replace all the currently unused bundles --such as for the CommonAural properties, that would be identical for a very large number of FOs-- with one instance, shared by the different FOs.

Would already make a neat difference, I think...



Reply via email to