Reported by Daniel Noll on fop-users@ The FO in attachment currently fails w/ FOP trunk, because the percentages for top/right/bottom/left are not resolved correctly. I think I've found a fix, patch also attached for reference. Can anyone confirm that the output PDF is the result one would expect? I think it's a correct interpretation of the Rec., but I'm not sure. With my fix, the percentages are based on the height/width of the outer block-container (which would generate the nearest ancestor reference area?)
Created attachment 19744 [details] source FO
Created attachment 19745 [details] proposed fix
Created attachment 19746 [details] PDF result after applying the patch
I think this is a step in the right direction, but I believe the PercentBase shouldn't be LengthBase.CONTAINING_REFAREA_HEIGHT but LengthBase.CONTAINING_BLOCK_HEIGHT. i-p-d, b-p-d, width and height are all using CONTAINING_BLOCK_WIDTH/HEIGHT as per the spec. top, left etc. are also defined in terms of the containing block, not the nearest ancestor reference area. In your example, that would place all three inner b-cs at the upper edge of the block-container's content area because the block they are enclosed in doesn't have a height in this case. Only if you remove the block between the inner and outer b-c will the vertical positioning work again. It's what I would expect in terms of behaviour.
(In reply to comment #4) > I think this is a step in the right direction, but I believe the PercentBase > shouldn't be LengthBase.CONTAINING_REFAREA_HEIGHT but > LengthBase.CONTAINING_BLOCK_HEIGHT. i-p-d, b-p-d, width and height are all using > CONTAINING_BLOCK_WIDTH/HEIGHT as per the spec. top, left etc. are also defined > in terms of the containing block, not the nearest ancestor reference area. Aaah, OK, now I think I get it. The spec (I only checked 1.1) explicitly alters the original CSS wording 'containing block' to 'nearest ancestor reference area' for interpreting top/left/bottom/right (and in the absolute-position property), but only where it comes to the positioning (100% to the left of /what/?), not in the definition of the percent-base (100% of /what/ to the left of ...?) Subtle one, I must say. :-) I'll adapt shortly.
Re-ran the example file through FOP Trunk, and I agree with the interpretation. Removing the surrounding fo:block leads to an expected placement of the block-containers. So, nothing to fix. Just one less Bugzilla entry to worry about...
batch transition to closed remaining pre-FOP1.0 resolved bugs