Victor Mote wrote:
FOP Developers:

This has been kicked around recently, but I realized that it may be
beneficial to go ahead and propose a change to get things going. The issue
of how Properties are stored in the FO Tree is in play. Since we now have FO
Tree pretty well isolated, I see some benefits to nailing down an API for it
that should be durable enough to work for any scheme that is used for
storing property values.

I propose that public "get" methods be used to retrieve FO Tree property
values, and that the data behind these values be made as private as
possible. The methods should be given a name based on the XSL-FO Standard.
For example, the "max-width" property should be accessed using the method
"getMaxWidth". The values returned should be the "refined" values.

1. The purpose here is to separate the storage of the property values from
their presentation (API) to the rest of the system. This opens the door for
later changes to the storage without disrupting the remainder of the system.
2. This could perhaps be implemented for now only in FObj (??).
3. This is not directly relevant to the question, but needs to be addressed
from the "big picture" standpoint. With the FO Tree mostly isolated, and
LayoutStrategy implemented, the issue of whether a certain feature is
implemented or not moves from the FO Tree to the specific LayoutStrategy.
Each LayoutStrategy eventually needs to track which objects and properties
it supports. The FO Tree should always store and return the data, without
regard to whether it can be used or not. In the future, our properties.xml
file, "compliance" page, and perhaps other things need to handle this. The
LayoutStrategy needs to be the entity that reports on whether a feature is
supported (perhaps using a scheme similar to properties.xml).
4. If accepted, this would be a great project for one of the new developers
to tackle. I don't mean to volunteer anyone, but it might be a good "feet
wet" project.

In, all of the property values are implementations of fop.datatypes.PropertyValue. Every PropertyValue must be able to report its type as an int. Every PropertyValue must also have a Property with which it is associated, and must be able to report this, again as an int. 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. That, it seems to me, is as far as the FO Tree can take things. What are the "get" methods going to return? In, they will always return a value of type PropertyValue. This proposal seems to imply that the type returned by the accessors will depend on the type supported by the Property. Take MaxWidth. What value will be returned? An int, representing the number of millipoints? An Integer? A Length object? 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.

The resolution of properties within the FO Tree has dependencies on the resolution of areas in the Area Tree.

Peter B. West <>

Reply via email to