https://issues.apache.org/bugzilla/show_bug.cgi?id=46160
--- Comment #6 from Andreas L. Delmelle <adelme...@apache.org> 2009-03-03 14:38:20 PST --- (In reply to comment #5) > It actually depends on how landscape tables are implemented by the DocBook > XSLT > stylesheets. I believe they use an fo:block-container with a > reference-orientation of 90 or -90, in which case I don't even know what the > behaviour is supposed to be. But we can always try to have a look. A rotated block-container (+/-90) with auto-width/-height and a nested table => the block-container's height/bpd will be equal to the table's height/bpd, but since the block-container is also rotated WRT the page/region-body, we only get possible situations of overflow in inline-progression-direction. Either the block-container's content is too large to fit in the available width --example: table inline-progression-dimension="200%"-- or the block-container grows too high --due to added table-rows-- thus exceeding the page width. The governing "overflow" and "clip" properties determine what happens with the content exceeding the reference-area boundaries. Once you specify explicit dimensions on the block-container, IIC FOP interprets this to be an unbreakable piece of content. Testing some combinations, I've just noticed a small error in FOP Trunk: reference-orientation is treated as an inherited property, while it most certainly is not. Since a lot of tests seem to be depending on it, it may take a while to fix this, although, purely codewise, it's only a matter of changing a boolean switch in FOPropertyMapping... :-/ -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
