[Glen Mazza]

... 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.


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.


Reply via email to