Changing orientation with fo:block-container holding a table

[Alexander Stamenov <as...@gmail.com>]

Greetings to all!

 I am using fop v 0.94 on a Windows XP box.
 I have the task to transform some XML into XSL-FO and part of that
XML is actually xhtml containing tables.
 Some of those tables are wider than a standard A4 page, so I wanted
to rotate them using <fo:block-container reference-orientation="90"
/>. But I stumbled upon a problem that cannot find a solution for.
 The table is rotated very nicely but the problem occurs if the table
cannot fit in the container. The rendering of the table continues to
the end of the page (right side in the 90 case) and after that it is
continued on the next page. What I think is a bug or misuse by me is
that the transition to the next page should occur when the
block-container ends. The fact that the table header is re-rendered at
the point where the correct transition should occur makes me speculate
that this might be a bug.

 Can you please refer to any solutions to this problem? And also
should this also be posted to fop-dev mailing list?

 Regards,
 Alexander

Re: Changing orientation with fo:block-container holding a table

[Andreas Delmelle <an...@telenet.be>]

On May 7, 2008, at 18:24, Andreas Delmelle wrote:

Just realized that it came out a bit wrong:

>
> This looks buggy indeed, but I'm not 100% certain what the bug is  
> exactly (or even if there is one).
> The more I think about, the more correct the behavior seems to be.

I did not mean the 'behavior', but FOP's interpretation.

On top of that:
>
> BUT: The available space in block-progression-dimension for the  
> table would, still be the reference-area's block-progression- 
> dimension (the block-container's height, not the page-width) [?]

Right now, you have situation of overflow, rather than a break (with  
0.95). As far as I understand, 0.94 was wrong to break the table there.

The block-container overflows the region-body in inline-progression- 
dimension, hence no page-break.

Strange as it may seem, you would only get a page-break if the inline- 
progression-dimension of the block-container exceeds the available  
space in block-progression-dimension.

> At least this interpretation is reflected in 0.95, where I don't  
> see the header appear anymore.
> If not rotated, then the block-container can grow to fit the table  
> on one page, so I see no page-break.
>
> OTOH, if I switch to 16cm block-progression dimension, with a  
> rotated region-body then the block-container also does not break,  
> where I'd expect it to...

I think I made an interpretation error here. Rotating the region- 
body, also does not suddenly swap bpd and ipd.
We will only get a page-break if the flow exceeds the available space  
in block-progression-direction (the page-height), but overflow in  
inline-progression-direction, hence no break.

Even so, when you specify a bpd on the block-container into which the  
entire table fits, without breaks, then the block-container will not  
be broken. Only its contents will overflow the available page-height  
(read: with explicit bpd, even rotating the entire page does not help).

Maybe there's something clever you can pull off with nested block- 
containers. Another idea may be to give the region-body less height,  
but that would not work if the block-container appears among other  
content. :/

In any case, the only way you can influence ipd-bpd direction  
relative to the flow, is to switch to a different writing-mode, but  
FOP is currently still severely limited in this area.


Cheers

Andreas

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org

Re: Changing orientation with fo:block-container holding a table

[Andreas Delmelle <an...@telenet.be>]

On May 7, 2008, at 17:04, Alexander Stamenov wrote:

Hi

> The table is rotated very nicely but the problem occurs if the table
> cannot fit in the container. The rendering of the table continues to
> the end of the page (right side in the 90 case) and after that it is
> continued on the next page. What I think is a bug or misuse by me is
> that the transition to the next page should occur when the
> block-container ends. The fact that the table header is re-rendered at
> the point where the correct transition should occur makes me speculate
> that this might be a bug.

This looks buggy indeed, but I'm not 100% certain what the bug is  
exactly (or even if there is one).
The more I think about, the more correct the behavior seems to be.

What I found out so far, is that it works if you specify the  
reference-orientation on the region-body, and leave it off the block- 
container.

Now, it seems a bit problematic IMO, since:
- the block-container has no specified height => auto-height, which  
means the total height should be equal to the content-height
- that height will only increase in case the block-container's  
content overflows the available space in block-progression-direction

Contrary to what one could assume (and what I once believed as well),  
the reference-orientation property has no influence on the  
correspondence mapping. This means that, even though you have rotated  
the block-container, inline-progression-dimension will still  
correspond to width. This seems to work OK: the block-container is  
16cm wide.

BUT: The available space in block-progression-dimension for the table  
would, still be the reference-area's block-progression-dimension (the  
block-container's height, not the page-width) [?]

At least this interpretation is reflected in 0.95, where I don't see  
the header appear anymore.
If not rotated, then the block-container can grow to fit the table on  
one page, so I see no page-break.

OTOH, if I switch to 16cm block-progression dimension, with a rotated  
region-body then the block-container also does not break, where I'd  
expect it to...


Cheers

Andreas

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org