Hi, Andreas Delmelle wrote: > 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.
This is an interesting interpretation. There is some discussion about that on the following bug report: https://issues.apache.org/bugzilla/show_bug.cgi?id=46160 One could return the question, taking the point of view of the children elements of the rotated block-container: when should that content be broken over to the next page? When its block-progression-dimension exceeds the available space in block-progression-direction. That is, when the after-edge of the block-container’s reference-area is reached, which corresponds to the end-edge of the region-body being reached (roughly speaking; to be exact: when the end-edge of the parent normal-flow-reference-area is reached). Hence the conclusion I made on the above bug report. Basically, I fail to see anything in the Recommendation that would not allow the content inside the rotated block-container to be broken over pages. > 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. (*) > <snip/> Vincent --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
