You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-users@xmlgraphics.apache.org by bonekrusher <dj...@yahoo.com> on 2009/09/04 21:22:39 UTC
fo:table breaks in fo:block-container
Hi,
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?
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: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: fo:table breaks in fo:block-container
Posted by bonekrusher <dj...@yahoo.com>.
Thanks Andreas,
A bit over my head :). I guess I can break the tables up as the documents is
not often updated.
Thanks again
Phil
--
View this message in context: http://www.nabble.com/fo%3Atable-breaks-in-fo%3Ablock-container-tp25300387p25303179.html
Sent from the FOP - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: fo:table breaks in fo:block-container
Posted by Vincent Hennebert <vh...@gmail.com>.
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: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: fo:table breaks in fo:block-container
Posted by Andreas Delmelle <an...@telenet.be>.
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.
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.
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...
Regards,
Andreas Delmelle
mailto:andreas.delmelle.AT.telenet.be
jabber: mandreas@jabber.org
skype: adlm0608
---
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: fo:table breaks in fo:block-container
Posted by Andreas Delmelle <an...@telenet.be>.
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.
Regards,
Andreas Delmelle
mailto:andreas.delmelle.AT.telenet.be
jabber: mandreas@jabber.org
skype: adlm0608
---
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: fo:table breaks in fo:block-container
Posted by Vincent Hennebert <vh...@gmail.com>.
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: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: fo:table breaks in fo:block-container
Posted by Andreas Delmelle <an...@telenet.be>.
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: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
>
Regards,
Andreas Delmelle
mailto:andreas.delmelle.AT.telenet.be
jabber: mandreas@jabber.org
skype: adlm0608
---
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org