Re: Job Change

2007-06-28 Thread richard
Andreas L Delmelle writes:
  On Jun 26, 2007, at 16:08, [EMAIL PROTECTED] wrote:
  
  Hi Richard,
  
   Please note that as of this Friday I will no longer be working at
   Geoquip. Any e-mail directed to [EMAIL PROTECTED]
   on matters concerning FOP is unlikely to get any meaningful
   response. 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 (?)

Yes. I'll take another look asap,

Richard



Re: Job Change

2007-06-27 Thread Andreas L Delmelle

On Jun 26, 2007, at 16:08, [EMAIL PROTECTED] wrote:

Hi Richard,


Please note that as of this Friday I will no longer be working at
Geoquip. Any e-mail directed to [EMAIL PROTECTED]
on matters concerning FOP is unlikely to get any meaningful
response. 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).


If you take testcase 'block-container_content_size_percentage.xml'  
for example, and run it separately, you'll notice the infamous  
'Cannot find LM to handle given FO for  LengthBase' messages. All the  
other warnings are a result of this error.


Still have to play with it some more first to say for sure why this  
happens (and to find out whether these cause all of the errors, or if  
a few are caused by other changes).


Stay tuned.


Cheers,

Andreas



Re: Job Change

2007-06-27 Thread Andreas L Delmelle

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