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.
Proposal: 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. Discussion: 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. My vote: +1 Victor Mote