... what's your opinion on switching to FO Constants at this time? They probably will not give us the rate of return that property constants have; but there may be future indexing or processing advantages with them. I'm not strong one way or the other on them.
Since then, you have removed the unused support for elementTable, which was the only place a FO constanst id was used. So I would delay the implementation of FO ids until that future arrives.
http://marc.theaimsgroup.com/?l=fop-dev&m=107182754300725&w=2
Your solution in your email does not look difficult to
implement, but as a simplification, how about just
implementing getElementId() within FONode to query an
new ID if its value is unintialized, say, -1, and to
store that value with the FONode, *instead of* having
each Extension FO's implement that query & store
function themselves?
That would also work, but the beauty of having each extension FO do the work is that it saves the size of an int (4 bytes) for each instance of a FONode. In my mail, the extension stores the id value in a static vrbl so it doesn't weight down every FONode object.
And it includes the properties that are valid for all the children element of each FO. That is what the large while loop does when it calls mergeContent.
OK--but to satisfy the spec, we probably need to add a
static boolean array for the properties, defining
true/false of whether each property is "inheritable".
Right, my patch stores that array in PropertyListBuilder.inherit.
Because one can attach an inheritable property to any FO, regardless of whether or not it is relevant for it or its children, we don't want to report an error if the user chooses to do so--we can query this static array to determine that we should just ignore the property instead.
A good point, my patch just reports an error when a property is specified that isn't relevant for the FO or any of its children.
regards, finn
