AW: AW: page break in table cells
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.delme...@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-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
AW: AW: page break in table cells
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.datt...@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.delme...@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-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
AW: page break in table cells
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.delme...@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-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
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-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
