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 Georg Datterl <ge...@geneon.de> on 2009/03/11 13:35:10 UTC
page break in table cells
Hi everybody,
I have attached a fo-file which contains a table with two columns and one row. The first cells contains one text block which should cover the whole length of the page and half the width of the page. At the end of the page, the text should flow to the next page and so on. The second column contains three text blocks, which should be placed on the first three pages. So I put a break.before="page" on the second and third block.
The second column is broken into three pages just fine. But the first column is broken at the same points, so on the first two pages, the first column contains just as much text as the second column, only on the last page the end of the first column is lower than the end of the second one.
Instead of
XXX AAA
XXX
-------
XXX BBB
XXX
-------
CCC
-------
I get
XXX AAA
-------
XXX BBB
-------
XXX CCC
XXX
-------
I already tried three rows and a number-rows-spanned for the first column, but that didn't change anything. Table markers are not yet implemented and I'm fresh out of ideas at the moment. Does anybody know of a way to get the layout I need?
Regards,
Georg Datterl
------ Kontakt ------
Georg Datterl
Geneon media solutions gmbh
Gutenstetter Stra�e 8a
90449 N�rnberg
HRB N�rnberg: 17193
Gesch�ftsf�hrer: Yong-Harry Steiert
Tel.: 0911/36 78 88 - 26
Fax: 0911/36 78 88 - 20
www.geneon.de
Weitere Mitglieder der Willmy MediaGroup:
IRS Integrated Realization Services GmbH: www.irs-nbg.de
Willmy PrintMedia GmbH: www.willmy.de
Willmy Consult & Content GmbH: www.willmycc.de
AW: AW: page break in table cells
Posted by Georg Datterl <ge...@geneon.de>.
Hi Andreas,
Forget I said anything. The difference comes from the printer or acrobat adding 5mm margin on the paper and then scaling everything down. If I take that into account, the numbers add up.
Regards,
Georg Datterl
------ Kontakt ------
Georg Datterl
Geneon media solutions gmbh
Gutenstetter Straße 8a
90449 Nürnberg
HRB Nürnberg: 17193
Geschäftsführer: Yong-Harry Steiert
Tel.: 0911/36 78 88 - 26
Fax: 0911/36 78 88 - 20
www.geneon.de
Weitere Mitglieder der Willmy MediaGroup:
IRS Integrated Realization Services GmbH: www.irs-nbg.de
Willmy PrintMedia GmbH: www.willmy.de
Willmy Consult & Content GmbH: www.willmycc.de
-----Ursprüngliche Nachricht-----
Von: Georg Datterl [mailto:georg.datterl@geneon.de]
Gesendet: Freitag, 13. März 2009 15:33
An: fop-users@xmlgraphics.apache.org
Betreff: AW: AW: page break in table cells
Hi Andreas,
> Assuming nothing exotic with writing-mode or reference-orientation,
> this would be the "bpd" or "bpda". IIC, the difference between the two
> is that one takes into account the borders and padding, while the
> other only refers to the content. I'd have to check an example to say
> for sure which is which.
Of course it's not as easy as I thought. Would you mind having a look at the attached fo-file? It contains some stuff I don't think relevant for my problem (but I may be wrong), but the interesting part are a few blocks labeled L15, L25, L35, R1a5 and R1b5. I gave them a background color to find them again, but when I generated the area tree and the pdf, the area tree blocks' bpd and bpda don't fit the mm size of the coloured areas in the pdf. For example, L15 gives me 88104 millipoint, translated into 31.081133mm, but measuring results in no more than 30mm. L25 gives 215808 millipoint, translated into 76.13226mm, measured 73mm. Why?
Regards,
Georg Datterl
------ Kontakt ------
Georg Datterl
Geneon media solutions gmbh
Gutenstetter Straße 8a
90449 Nürnberg
HRB Nürnberg: 17193
Geschäftsführer: Yong-Harry Steiert
Tel.: 0911/36 78 88 - 26
Fax: 0911/36 78 88 - 20
www.geneon.de
Weitere Mitglieder der Willmy MediaGroup:
IRS Integrated Realization Services GmbH: www.irs-nbg.de
Willmy PrintMedia GmbH: www.willmy.de
Willmy Consult & Content GmbH: www.willmycc.de
-----Ursprüngliche Nachricht-----
Von: Andreas Delmelle [mailto:andreas.delmelle@telenet.be]
Gesendet: Donnerstag, 12. März 2009 20:01
An: fop-users@xmlgraphics.apache.org
Betreff: Re: AW: page break in table cells
On 12 Mar 2009, at 09:44, Georg Datterl wrote:
> But your solution only makes the first column blocks 5cm longer. If
> there's more space in the first column, it's not used. And if the
> second column block + 5cm is longer than page height, the empty block
> flows to the second page and the text block for the second page is
> moved to the third page. I'm afraid, that's not dynamical enough for
> me.
I thought as much...
> In my real live case, I have a table in the right column which can
> spread over multiple pages. In the left column I have some images
> which should pe printed on each page, no matter how many pages the
> table spans. At the moment I generate the table and one set of images,
> have a look at the area tree and find out, how many pages the table
> spans. Then I go back to the fo-file and insert image blocks as
> needed. I guess, I could ask the area tree for the size of the image
> block and the sizes of the table blocks and then calculate a
> space-after or padding-after for the image blocks instead of the page
> breaks. Does that sound possible and which area tree attribute should
> I look at to get the realtime height of the blocks?
Definitely sounds possible. Assuming nothing exotic with writing-mode or reference-orientation, this would be the "bpd" or "bpda". IIC, the difference between the two is that one takes into account the borders and padding, while the other only refers to the content. I'd have to check an example to say for sure which is which.
Since the block in the first cell will be broken, you will obviously need to combine the block-progression-dimension of all three blocks, but that should not pose a problem, I think...
HTH!
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
AW: AW: page break in table cells
Posted by Georg Datterl <ge...@geneon.de>.
Hi Andreas,
> Assuming nothing exotic with writing-mode or reference-orientation,
> this would be the "bpd" or "bpda". IIC, the difference between the two
> is that one takes into account the borders and padding, while the
> other only refers to the content. I'd have to check an example to say
> for sure which is which.
Of course it's not as easy as I thought. Would you mind having a look at the attached fo-file? It contains some stuff I don't think relevant for my problem (but I may be wrong), but the interesting part are a few blocks labeled L15, L25, L35, R1a5 and R1b5. I gave them a background color to find them again, but when I generated the area tree and the pdf, the area tree blocks' bpd and bpda don't fit the mm size of the coloured areas in the pdf. For example, L15 gives me 88104 millipoint, translated into 31.081133mm, but measuring results in no more than 30mm. L25 gives 215808 millipoint, translated into 76.13226mm, measured 73mm. Why?
Regards,
Georg Datterl
------ Kontakt ------
Georg Datterl
Geneon media solutions gmbh
Gutenstetter Stra�e 8a
90449 N�rnberg
HRB N�rnberg: 17193
Gesch�ftsf�hrer: Yong-Harry Steiert
Tel.: 0911/36 78 88 - 26
Fax: 0911/36 78 88 - 20
www.geneon.de
Weitere Mitglieder der Willmy MediaGroup:
IRS Integrated Realization Services GmbH: www.irs-nbg.de
Willmy PrintMedia GmbH: www.willmy.de
Willmy Consult & Content GmbH: www.willmycc.de
-----Urspr�ngliche Nachricht-----
Von: Andreas Delmelle [mailto:andreas.delmelle@telenet.be]
Gesendet: Donnerstag, 12. M�rz 2009 20:01
An: fop-users@xmlgraphics.apache.org
Betreff: Re: AW: page break in table cells
On 12 Mar 2009, at 09:44, Georg Datterl wrote:
> But your solution only makes the first column blocks 5cm longer. If
> there's more space in the first column, it's not used. And if the
> second column block + 5cm is longer than page height, the empty block
> flows to the second page and the text block for the second page is
> moved to the third page. I'm afraid, that's not dynamical enough for
> me.
I thought as much...
> In my real live case, I have a table in the right column which can
> spread over multiple pages. In the left column I have some images
> which should pe printed on each page, no matter how many pages the
> table spans. At the moment I generate the table and one set of images,
> have a look at the area tree and find out, how many pages the table
> spans. Then I go back to the fo-file and insert image blocks as
> needed. I guess, I could ask the area tree for the size of the image
> block and the sizes of the table blocks and then calculate a
> space-after or padding-after for the image blocks instead of the page
> breaks. Does that sound possible and which area tree attribute should
> I look at to get the realtime height of the blocks?
Definitely sounds possible. Assuming nothing exotic with writing-mode or reference-orientation, this would be the "bpd" or "bpda". IIC, the difference between the two is that one takes into account the borders and padding, while the other only refers to the content. I'd have to check an example to say for sure which is which.
Since the block in the first cell will be broken, you will obviously need to combine the block-progression-dimension of all three blocks, but that should not pose a problem, I think...
HTH!
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
AW: AW: page break in table cells
Posted by Georg Datterl <ge...@geneon.de>.
Hi Andreas,
> Definitely sounds possible.
Good. Although coercing FOP into this doesn't feel morally right.
> Assuming nothing exotic with writing-mode or reference-orientation,
> this would be the "bpd" or "bpda". IIC, the difference between the
> two is that one takes into account the borders and padding, while
> the other only refers to the content. I'd have to check an example
> to say for sure which is which.
No problem, I'll try both and take the bigger one.
> Since the block in the first cell will be broken, you will obviously
> need to combine the block-progression-dimension of all three blocks,
> but that should not pose a problem, I think...
Actually, I'll need the actual values for the first block (will most likely not start at page start), maybe the last page (I can implement another feature nearly for free with this, I think) and one page inbetween.
Regards,
Georg Datterl
------ Kontakt ------
Georg Datterl
Geneon media solutions gmbh
Gutenstetter Straße 8a
90449 Nürnberg
HRB Nürnberg: 17193
Geschäftsführer: Yong-Harry Steiert
Tel.: 0911/36 78 88 - 26
Fax: 0911/36 78 88 - 20
www.geneon.de
Weitere Mitglieder der Willmy MediaGroup:
IRS Integrated Realization Services GmbH: www.irs-nbg.de
Willmy PrintMedia GmbH: www.willmy.de
Willmy Consult & Content GmbH: www.willmycc.de
-----Ursprüngliche Nachricht-----
Von: Andreas Delmelle [mailto:andreas.delmelle@telenet.be]
Gesendet: Donnerstag, 12. März 2009 20:01
An: fop-users@xmlgraphics.apache.org
Betreff: Re: AW: page break in table cells
On 12 Mar 2009, at 09:44, Georg Datterl wrote:
> But your solution only makes the first column blocks 5cm longer. If
> there's more space in the first column, it's not used. And if the
> second column block + 5cm is longer than page height, the empty block
> flows to the second page and the text block for the second page is
> moved to the third page. I'm afraid, that's not dynamical enough for
> me.
I thought as much...
> In my real live case, I have a table in the right column which can
> spread over multiple pages. In the left column I have some images
> which should pe printed on each page, no matter how many pages the
> table spans. At the moment I generate the table and one set of images,
> have a look at the area tree and find out, how many pages the table
> spans. Then I go back to the fo-file and insert image blocks as
> needed. I guess, I could ask the area tree for the size of the image
> block and the sizes of the table blocks and then calculate a
> space-after or padding-after for the image blocks instead of the page
> breaks. Does that sound possible and which area tree attribute should
> I look at to get the realtime height of the blocks?
HTH!
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: AW: page break in table cells
Posted by Andreas Delmelle <an...@telenet.be>.
On 12 Mar 2009, at 09:44, Georg Datterl wrote:
> But your solution only makes the first column blocks 5cm longer. If
> there's more space in the first column, it's not used. And if the
> second column block + 5cm is longer than page height, the empty
> block flows to the second page and the text block for the second
> page is moved to the third page. I'm afraid, that's not dynamical
> enough for me.
I thought as much...
> In my real live case, I have a table in the right column which can
> spread over multiple pages. In the left column I have some images
> which should pe printed on each page, no matter how many pages the
> table spans. At the moment I generate the table and one set of
> images, have a look at the area tree and find out, how many pages
> the table spans. Then I go back to the fo-file and insert image
> blocks as needed. I guess, I could ask the area tree for the size of
> the image block and the sizes of the table blocks and then calculate
> a space-after or padding-after for the image blocks instead of the
> page breaks. Does that sound possible and which area tree attribute
> should I look at to get the realtime height of the blocks?
Definitely sounds possible. Assuming nothing exotic with writing-mode
or reference-orientation, this would be the "bpd" or "bpda". IIC, the
difference between the two is that one takes into account the borders
and padding, while the other only refers to the content. I'd have to
check an example to say for sure which is which.
Since the block in the first cell will be broken, you will obviously
need to combine the block-progression-dimension of all three blocks,
but that should not pose a problem, I think...
HTH!
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
AW: page break in table cells
Posted by Georg Datterl <ge...@geneon.de>.
Thanks for your help, Andreas,
But your solution only makes the first column blocks 5cm longer. If there's more space in the first column, it's not used. And if the second column block + 5cm is longer than page height, the empty block flows to the second page and the text block for the second page is moved to the third page. I'm afraid, that's not dynamical enough for me.
In my real live case, I have a table in the right column which can spread over multiple pages. In the left column I have some images which should pe printed on each page, no matter how many pages the table spans. At the moment I generate the table and one set of images, have a look at the area tree and find out, how many pages the table spans. Then I go back to the fo-file and insert image blocks as needed. I guess, I could ask the area tree for the size of the image block and the sizes of the table blocks and then calculate a space-after or padding-after for the image blocks instead of the page breaks. Does that sound possible and which area tree attribute should I look at to get the realtime height of the blocks?
Regards,
Georg Datterl
------ Kontakt ------
Georg Datterl
Geneon media solutions gmbh
Gutenstetter Straße 8a
90449 Nürnberg
HRB Nürnberg: 17193
Geschäftsführer: Yong-Harry Steiert
Tel.: 0911/36 78 88 - 26
Fax: 0911/36 78 88 - 20
www.geneon.de
Weitere Mitglieder der Willmy MediaGroup:
IRS Integrated Realization Services GmbH: www.irs-nbg.de
Willmy PrintMedia GmbH: www.willmy.de
Willmy Consult & Content GmbH: www.willmycc.de
-----Ursprüngliche Nachricht-----
Von: Andreas Delmelle [mailto:andreas.delmelle@telenet.be]
Gesendet: Mittwoch, 11. März 2009 20:08
An: fop-users@xmlgraphics.apache.org
Betreff: Re: page break in table cells
On 11 Mar 2009, at 19:58, Andreas Delmelle wrote:
> I did manage to get very close by adding an empty block in the AAA
> cell after the main block, and specifying some forced space-before on
> it. In that case, the algorithm is tricked into thinking that there is
> more 'content' in that cell, and allows more lines from the first
> column to appear on the first page.
Come to think of it: this approach could solve the problem with using just one fo:table-row as well. The only thing to remember there, is to also set space-before.conditionality to retain. Since the page-break happens within the confines of the table-cell, there is no fence between the empty block, and the following one, so this would result in the space being discarded.
So, to summarize the proposed workaround/FO hack, in the original sample, you would only need to add something like:
... This text should be on the first page.</fo:block>
<fo:block space-before.optimum="5cm"
space-before.precedence="force"
space-before.conditionality="retain" />
And probably also between the second and third pages, to make sure all of the remaining content in the first column ends up on the second page.
HTH!
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: page break in table cells
Posted by Andreas Delmelle <an...@telenet.be>.
On 11 Mar 2009, at 19:58, Andreas Delmelle wrote:
> I did manage to get very close by adding an empty block in the AAA
> cell after the main block, and specifying some forced space-before
> on it. In that case, the algorithm is tricked into thinking that
> there is more 'content' in that cell, and allows more lines from the
> first column to appear on the first page.
Come to think of it: this approach could solve the problem with using
just one fo:table-row as well. The only thing to remember there, is to
also set space-before.conditionality to retain. Since the page-break
happens within the confines of the table-cell, there is no fence
between the empty block, and the following one, so this would result
in the space being discarded.
So, to summarize the proposed workaround/FO hack, in the original
sample, you would only need to add something like:
... This text should be on the first page.</fo:block>
<fo:block space-before.optimum="5cm"
space-before.precedence="force"
space-before.conditionality="retain" />
And probably also between the second and third pages, to make sure all
of the remaining content in the first column ends up on the second page.
HTH!
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: page break in table cells
Posted by Andreas Delmelle <an...@telenet.be>.
On 11 Mar 2009, at 19:15, Andreas Delmelle wrote:
>
> <snip />
> It seems like three rows with a forced rowspan of two set in the
> first column, is what is needed to trigger the desired result here.
Just tried with a fresh checkout, and FOP Trunk chooses a less
desirable layout in this case.
XXX AAA
-------
XXX BBB
XXX
XXX
-------
CCC
Although correct, the first break yields better demerits if the
content in both cells for the first row is roughly the same. What
happens on the next page does not influence this.
I did manage to get very close by adding an empty block in the AAA
cell after the main block, and specifying some forced space-before on
it. In that case, the algorithm is tricked into thinking that there is
more 'content' in that cell, and allows more lines from the first
column to appear on the first page.
HTH!
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: page break in table cells
Posted by Andreas Delmelle <an...@telenet.be>.
On 11 Mar 2009, at 13:35, Georg Datterl wrote:
Hi Georg
> Instead of
>
> XXX AAA
> XXX
> -------
> XXX BBB
> XXX
> -------
> CCC
>
> -------
>
> I get
>
> XXX AAA
> -------
> XXX BBB
> -------
> XXX CCC
> XXX
> -------
I'm not certain, but I have a feeling this follows from the way the
Knuth algorithm implementation for tables works. The result you get
has better overall demerits because it looks nicer. That is: the
content is more evenly distributed over the pages than in the first
case.
IIC, FOP will always do its best to avoid layouts like the first,
where you have one page where only one table-part contributes
something. Such a layout will only be chosen if there really is no
other way...
> I already tried three rows and a number-rows-spanned for the first
> column, but that didn't change anything.
For the same reason, I think: better distribution of content over the
available space.
> Table markers are not yet implemented and I'm fresh out of ideas at
> the moment. Does anybody know of a way to get the layout I need?
>
It seems like three rows with a forced rowspan of two set in the first
column, is what is needed to trigger the desired result here.
Strange thing I'll have to investigate on my end is that, if I render
your sample through FOP Trunk (that is, my sandbox), there is no
content on the third page at all. The block is just gone. I get a
blank third page as a result... :-/
Regards
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org