On 04 Sep 2009, at 21:22, bonekrusher wrote:
Hi Phil
I have a table inside a fo:block-container. The block-container's
orientation is 90 degrees (see attached). When the table rows
exceeds the
table width, the table does not break to the next page. I've
attached a
working example. How do I get the the table to break to the next page?
Short answer: you can't. Not with FOP, at any rate.
Longer answer:
I remember playing with a similar case in the past, and realized back
then that what you seem to expect, is strictly speaking not possible
in standard XSL-FO 1.1, unless you were to rotate the entire region-
body.
IIRC, some commercial implementations offer proprietary extensions to
allow such breaks to be produced. FOP unfortunately does not, yet...
As for the standard: When would the block-container break to the next
page?
Answer: when its block-progression-dimension exceeds the available
space in block-progression-direction.
Now, keep in mind that reference-orientation appears to change block/
inline-progression-direction for everything that lies *inside* the b-c
(= it establishes a new coordinate system *within* the b-c's viewport-
area).
The b-c's height is still its extent in the block-progression-
direction of the region, which will be determined by the width of its
content (assuming height="auto", as in your sample)
If the content's height is greater than the region-body's width, then
that is considered overflow in inline-progression-direction. If we had
overflow="scroll" implemented for AWT, you would at most get a
scrollbar.
From the point of view of the flow, the block-container's height can
never exceed the height of the region-body, unless the content's width
is greater than the region's height.
Even then, FOP chooses to let the content overflow, rather than
breaking. Rotated block-containers are never broken. (*)
ATM, I'm unsure as to how much/little effort it would take to change
this. It seems quite possible to allow the nested Breaker to return
multiple parts instead of removing all breaks, as it does now. That's
the easy part.
I see a possible difficulty for a block-container that starts, say in
the middle of a page. On the next page, there is more available space
for the content-width, but at the time the breaks are first computed,
we don't really know yet how much that will be. We can only assume it
is equal to the 'current' available height.
Support for changing page-width has been added to Trunk recently, but
when only the page-height changes, nothing special happens, and we
could still get overflow as a result...
(*) Technically: for regular block-containers, the element list is
inlined into the eventual sequence returned by the FlowLayoutManager
to the PageBreaker. On the other hand, rotated or absolute-positioned
block-containers are processed/broken by a nested
BlockContainerLayoutManager.BlockContainerBreaker, whose
isSinglePartFavored() returns true. Basically, what the outer
PageBreaker gets to see here, is a single block.
http://www.nabble.com/file/p25300387/example2.png example2.png
http://www.nabble.com/file/p25300387/example.fo example.fo
Thanks,
Phil
--
View this message in context:
http://www.nabble.com/fo%3Atable-breaks-in-fo%3Ablock-container-tp25300387p25300387.html
Sent from the FOP - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
Regards,
Andreas Delmelle
mailto:andreas.delmelle.AT.telenet.be
jabber: [email protected]
skype: adlm0608
---
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
