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

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.



Reply via email to