Hi Andreas, Andreas Delmelle wrote: > On 07 Sep 2009, at 18:11, Andreas Delmelle wrote: > >> On 07 Sep 2009, at 12:22, Vincent Hennebert wrote: >> >>> 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. >> >> No. When it makes the block-container break to the next page, hence >> when its inline-progression-dimension exceeds the >> block-progression-dimension of the block-container.
Do you have pointers to the Recommendation where the above is stated? I’ve been looking for some for a while and haven’t been able to find any. What I found however were strong indications, in the description of fo:block-container, that the content inside a rotated block-container should be broken over pages: http://www.w3.org/TR/xsl11/#fo_block-container “the reference-area may be larger than the viewport-area and this may cause the ‘overflow’ property to operate.” and “The ‘repeat’ value of overflow can be used to generate multiple viewport/reference pairs if this is desired rather than clipping or scrolling.” > Note that this should normally change with XSL-FO 2.0, where in the > initial requirements (wish-list), there has been explicit demand to > define such 'vertical' breaks. If you’re thinking of what can be found under the following link: http://www.w3.org/TR/2008/WD-xslfo20-req-20080326/#N66228 then AFAIU that requirement is meant to address a different situation: “In case a table is split over multiple pages and both the rows and columns don’t fit a page...” This is different to a table that doesn’t fit in the block-progression-direction only, be it inside a rotated block or not. > Fact remains: the block-progression-direction of the flow does not > change at all due to the reference-orientation on the block-container. > > Difficult to see why other implementations would provide a proprietary > extension for this, if it's catered for by the Rec anyway... Thanks, Vincent --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
