On Jun 27, 2007, at 19:44, Andreas L Delmelle wrote:
On Jun 26, 2007, at 16:08, [EMAIL PROTECTED] wrote:
... Hopefully I will still get the chance to continue working
on FOP and I intend to take another look at the memory usage patches
asap,
I'm in the process of looking at your patch right now. I suppose
you've already seen the additional comment on the bug (?)
So far, I'm looking in the direction of two possible causes:
percentages or length-ranges (or both: percentages in/of length-
ranges).
OK, I think I've found the cause.
It is indeed related to percentages. If you change the example to
give each property a different percentage value, the warnings all
disappear. Seems to be the possible issue #2 I pointed to in my first
comments in Bugzilla 41044: the "50%" *cannot* be considered one and
the same for all four block-containers, even less so for width and
height, and that's exactly what does happen after applying the patch.
OTOH, the absolute "100pt" is the same one for all the block-
containers and for width and height, so that's definitely going in
the right direction.
The keys to solving the percentage-issue:
Note that percentages are never actually resolved until during
layout. At the time the property is parsed/created, there is not
enough context available to determine that in fact all those
percentages resolve to the same absolute value later on.
While it appears trivial /here/ to resolve these at parse-time, keep
in mind that the base-length might as well be another percentage, and
may be based on a length that is layout-dependent.
AFAIU, what happens here is roughly:
When the property is parsed, the percent-base of the 50% is set to
the first parent block-container, and its factor to 0.5. Based on
those two components, you decide to create a canonical 50%, that is
used for every occurrence of the string "50%" as an attribute value
for a length property.
For the first block-container, there are no foreseeable problems, as
the percent-base that is stored in the canonical instance is really
the same one, but...
For the second one, the percentage-resolution mechanism climbs up the
ancestry of the current layoutmanager to find the LM associated to
the 50%, and doesn't find it.
Cheers,
Andreas
