Finn Bock wrote:

One thing I'm missing here, for Finn's design below:

values[0] = null // always null.
values[1] = reference to a 'foo' Property instance
values[2] = reference to a 'baz' Property instance

Can't we just have, say, values[1] refer to the
parent's Property instance in cases where inheritance
is applicable?

I.e., for all those references to the 'foo' property
instance for the children of an FO where that value
would be inherited, we don't have to create a new
Property instance, just a reference to the inherited

Right, that is also the way I see it.

But if the problem is the *recursion* necessary to
determine the property instance to inherit--here, not
the memory problem, but processing speed--I'm thinking
of a PropertyWindow instance as follows:

A PropertyWindow would be used temporarily during FObj
property initialization to hold references to all the
property instances that would be relevant for that
FObj should a property not be explicitly defined. So, to populate the property instances for a
particular FObj, i.e., the "values" array:

Pardon me for repeating what might be obvious, but I'll like to take
a look at what information we want to store at each FObj. I can come
up with 3 different strategies:

1) Only store the specified properties. That is what HEAD does now.
2) Put the relevant properties in a fast Property[] array and the
   remaining specified properties in a HashMap. For fo:root the result
   would be an array of size 1 for the 'media-usage' property.
3) Expect to store every valid property. For fo:root that would mean
   allocating an array large enough to store every defined property.
   This is what my patch does, and the "values" array works as the

As I understand your PropertyWindow proposal, it would allow us to
implement no. 2) above. I'll try to come up with some numbers to see
how much memory that would use/save compared to 1) and 3).

Alt-design (trying the hyphen for a while) takes different approaches at different times. While building the subtree of any node, all of the properties are maintained in a HashMap, along with a BitSet of specified properties.

When the subtree construction is complete, the HashMap and BitSet are used to build the sparse array of only the relevant *resolved* property values (not properties - one of the differences with HEAD) and then thrown away.

This approach has to be modified in two environments - fo:static-content and fo:marker. In the case of fo:marker, the inherited environment is not known at parse time, and in the case of static-content, the appropriate fo:retrieve-marker subtrees are not know until the region-body area tree is constructed.

In general, the impact on storage of maintaining full details for fo:static-content and fo:marker will not be huge, even if these are parsed as encountered. However, the plan for alt-design is 1) not the parse an fo:marker subtree unless and until it is required, and 2) to re-parse fo:static-content for each page after the region-body area tree has been constructed. (I'm working on these modifications now.)

Peter B. West <>

Reply via email to