--- 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
> 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.