Hi Vincent, > To avoid that issue, remove the border on the outer block.
I wish I could. But the border is necessary. > Alternatively, set its conditionality to retain. Be careful though: the > conditionality can be set only on the relative property (border-after- > width), not the absolute one (border-bottom-width): > <fo:block border-after-width.length="0.4pt" > border-after-width.conditionality="retain"... That would not give me a border on each page, would it? Or is there a way to creatively use colapsing borders? 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: Vincent Hennebert [mailto:[email protected]] Gesendet: Dienstag, 27. Oktober 2009 16:45 An: [email protected] Betreff: Re: confusing tables again Hi Georg, Georg Datterl wrote: > Hi Vincent, > > I tried with the lates update, same result. See the two pdfs. Also attached > find the images. I assumed they would be unnecessary, since I explicitely > state content-height. Indeed; the problem was actually the font. Not having Arial FOP defaulted to Times, which has different metrics and was then giving a different result. After having replaced it with sans-serif I managed to reproduce your issue... ... And FOP's behaviour is actually perfectly fine. You defined a bottom border of 0.4pt on the block surrounding the big table. That little border is just enough to make the whole block not fit on the page, hence the page break you get on the first version. Without that border the table would fit on one page. In the second version with the additional block, the table itself becomes bigger than the page, so that block must be deferred to the next page. The width of the border defined on the outer block is conditional, so it must not appear at the bottom of the first page. And since without that border the inner table fits on the first page, FOP puts it there. To avoid that issue, remove the border on the outer block. Alternatively, set its conditionality to retain. Be careful though: the conditionality can be set only on the relative property (border-after-width), not the absolute one (border-bottom-width): <fo:block border-after-width.length="0.4pt" border-after-width.conditionality="retain"... > The footer image is unnecessary I guess, since it can't be included > anyway (without Jeremias' extension). > > Regards, > > Georg Datterl HTH, Vincent > ------ 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: Vincent Hennebert [mailto:[email protected]] > Gesendet: Montag, 26. Oktober 2009 11:30 > An: [email protected] > Betreff: Re: confusing tables again > > Hi Georg, > > Which version of FOP are you using? With the latest Trunk both files are > rendered the exact same way. The referred images aren't available though. Can > you try again with the latest Trunk, or send the images? > > Thanks, > Vincent > > > Georg Datterl wrote: >> Hi everybody, >> >> It's me again and I'm still finding strange behaviours in regard to page >> breaks. I know the new layouting is just somewhere around the corner, but >> maybe you can find a workaround again. For those who came in late, here's >> what I do: >> >> I have a table with images in one column and a table in the second column. >> If the table breaks to a new page, on this page I need a copy of the images >> from the first page. So I generate the table with only the first image. Then >> I parse the area tree and find out, how many pages the table spans and how >> much space is left in the image column of the first page. Then I grab the >> image column, add an empty block spanning the remainder of the page, add the >> image (which is then displayed on the next page, of course), add another >> empty block and repeat for each page. >> >> withoutBlock.fo contains such a table. As you can see, the right table >> breaks to the second page and three rows are displayed there. On the first >> page you can already see a pink block below the image, this would be added >> after parsing the area tree. >> >> The second file, withBlock.fo contains a second pink block, which according >> to the data gained from area tree, should be displayed on the second page >> and should be exactly as high as the remaining table in the right column. >> That's the theory. >> >> When you run withBlock.fo through fop, you might be as surprised as I am: >> The table suddenly fits on one page and the newly added block sits on the >> second page all alone like a skunk at a cat fair. >> >> Why? And what can I do against it? I don't care whether the table needs one >> or two pages, but I want it to make a decision and then stick to it. >> >> Regards, >> >> Georg Datterl --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
