Integrating Alt-Design FO Tree into Redesign

Bridging the 0.20.0 -> 0.20.5 gap

Cleaning up org.apache.fop.apps

The org.apache.fop.apps package, in particular requires upgrading to compatibility with 0.20.5. To work on alt.design, the apps code at the time of branching was mercilessy hacked to provide a minimal front-end for alt.design. Logging, for instance, is still performed by MessageHandler.

Checkstyle

Anyone with an interest in the integration, but cautious about approaching the code would do a great service by cleaning the alt.design codebase up with Checkstyle. I have recently been developing with Eclipse and the 3.1.1 Checkstyle plugin, so a basic environment for such a cleanup process now exists.

Issues in the alt.design code

Tidying existing structure

Add corresponding properties handling

The properties all have unique integer values in alt.design, and for most purposes the properties are represented by these integer indices. The correspondence between property and integer is defined in { { { fo/PropNames.java } } }. This list also defines the order in which property attributes on FOs are processed. The list begins

All of this should ensure that, when a property with corresponding properties is processed all other values required for the resolution of those corresponding properties will have been resolved.

Attributes (property values) are handled in { { { fo/FoNode.processAttributes() } } }. This method cycles through attributes defined on an FO node in numerical property order. The point at which I originally intended corresponding property processing to occur is indicated by the comment

Accessing property values

No property objects

Only singleton property objects exist. The data in property objects is regarded as a set of constants. How are property values maintained? The property value objects (e.g. Numeric, Literal) are associated with Flow Objects. The property whose value these property value objects represents is maintained in the property value object itself as an integer property index. The list of these integers is maintained in { { { .../fo/PropNames.java } } } .

Storage of property values

The set of property values applicable to an FO is kept, when the building of an subtrees of the FO is completed, in the array { { { private PropertyValue[] sparsePropsSet; } } } The property indices of properties in { { { sparePropsSet } } } are contained in property index order in { { { private final int[] sparseIndices; } } } Both of these arrays have only enough elements to contain the applicable properties for the FO. In order to map from a property index to the associated { { { PropertyValue } } } in { { { sparsePropsSet } } } , the array { { { private final int[] sparsePropsMap; } } } is required. Indexed by property index, it contains the corresponding index into { { { sparsePropsSet } } } .

Given a property index property , the property value associated with the the index can be obtained by sparsePropsSet[ sparsePropsMap[property] ]

The accessor for property values within { { { .../fo/FONode.java } } } and descendants is the method public PropertyValue getPropertyValue(int property)

Potential problem with static-content

Depending on the results of an enquiry now before the xsl-editors, the handling of properties within static-content may have to change slightly. The above minimal scheme of properties data, compressed to only those properties which are relevant to a particular FO, builds the { { { sparsePropsSet } } } after the FO subtree of all of its children has been built. The assumption here is that properties which are not actaull applicable to the FO in question are no longer required. Any reference to such a property from within the FO's subtree (e.g. via the { { { FromNearestSpecifiedValue() } } } function) will have been resolved.

This may not be the case when marker subtrees are conceptually subpended to a node within static-content during the resolution of markers. In this case, for FOs within static-content, some indication of properties specified on the node may need to be kept.

Extending current design

Add support for FOP extensions

FOP extensions cannot simply be defined in isolation, because of the nature of pull parsing. In any case, the semantics of extensions require intervention in the code downstream of parsing. The immediate implications are that the pull parsing classes, including { { { xml/FoXMLEvent.java } } } and { { { xml/SyncedFoXmlEventsBuffer.java } } } will have to be extended to handle the fox: events, and the fo/flow classes, which effectively perform input XML validation, will have to be extended to accommodate extensions.

Tighter Area Tree integration

This is a large and interesting topic. It is driven by the need for Area Tree context information in order to resolve additive expressions involving percentages defined against enclosing areas. (More on this to come.)