https://issues.apache.org/bugzilla/show_bug.cgi?id=51245
--- Comment #2 from Vincent Hennebert <[email protected]> 2011-07-04 18:17:23 UTC --- Hi Alexander, Thanks for your simple test case. In short, this is because the content of the block-container doesn't fit within the given height. You must have seen the following warning given by FOP: "Content overflows the viewport of an fo:block-container in block-progression direction by 600 millipoints. Content will be clipped." If you extend the height of the block-container to 58pt then you should get what you want. If you're happy with that solution, brilliant. If for some reason you don't want to extend the height of the block-container accordingly, then you are hitting a bug in FOP whose gory details are below. In BlockContainerLM.getNextKnuthElementsAbsolute, FOP creates an instance of BlockContainerBreaker that in turn creates a PageBreakingAlgorithm instance. Since the content doesn't fit in the block-container, the algorithm breaks it into two parts. The second part just contains the last line, so most of the second part is filled with empty space (42.6pt in the present case). And this is this amount that is being taken into account to shift the content down to the bottom of the b-c. This is done in AbstractBreaker.addAreas ("if (pbp.difference != 0 && displayAlign == Constants.EN_AFTER) {"). 0 should be used instead. I don't currently have an idea of how to fix this issue. This part of the code is very tricky and even a minor modification may lead to regressions. Vincent -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
