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/10/22 17:05:02 UTC
confusing tables again
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
------ 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: confusing tables again
Posted by Georg Datterl <ge...@geneon.de>.
Hi Vincent,
I generated the footer, but did not add it to the table. But i would have added it to the inner table anyway. And I was working under one misconception. I thought, the result would be a table fitting one page.
Now (pending a final test generating 200 pages) it seems like the table takes two pages, before and after adding the block. Which probably means a second beer for you. :-) Thanks a lot!
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:vhennebert@gmail.com]
Gesendet: Donnerstag, 29. Oktober 2009 11:47
An: fop-users@xmlgraphics.apache.org
Betreff: Re: confusing tables again
Hi Georg,
Georg Datterl wrote:
> Hi Vincent,
>
> I have to admit, I did not quite understand why an invisible border, overridden by a hidden border would result in a visible border, but I think I applied your example to my table correctly. And it works, nearly.
The thing is, at the page break the table-footer is absent, so its after-border doesn't compete with the after-border of the table. So that latter is chosen, which results into a present (but invisible) border.
After the page break, when the table is finished, the footer is added, so this time its after-border specification prevails ('hidden' has higher priority than any other border style) and results into a null border. Indeed it's the border of the outer block that will be used.
> Now the table doesn't spread over two pages in any case, but before adding the block, I have one page and after adding the block, which should actually occupy all but only the free space in the left column, the outer border moves to the next page. Without table cells, but still, the line is on the second page (see example).
>
> Then I tried to shorten this block. Shortening it by a small amount (ca. 10pt) results in the block being moved to the second page. Shortening it by a larger amount (ca. 50pt) results in the block being on the first page, but three table rows being on the second page.
I'm not sure of what you did. I didn't see any table-footer in your sample file. So I've reproduced the trick on the first file you sent in that thread. I've also slightly corrected it: in the collapsing-border model half of the border resides in the margin, so doesn't count in the height calculation. So to simulate the border of the outer block you have to double its width.
To make it clear, all that trick is necessary only if you /don't/ want the border of the outer block replicated at each page break. Otherwise, you can just set its conditionality to retain as explained earlier.
HTH,
Vincent
> 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:vhennebert@gmail.com]
> Gesendet: Mittwoch, 28. Oktober 2009 16:01
> An: fop-users@xmlgraphics.apache.org
> Betreff: Re: confusing tables again
>
> Hi Georg,
>
> Georg Datterl wrote:
>> 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?
>
> Yes, that would. It's so tiny, nobody would see it, would it? :-)
>
>
>> Or is there a way to creatively use colapsing borders?
>
> That's an idea. You could define an invisible (same colour as background), retained bottom border on the outer table, overridden by a hidden bottom border on an empty table footer, with table-omit-footer-at-break="true". At the page break, the footer wouldn't be there, so the table border would win and account for the block's discarded border. After the page break, the footer would nullify the border and you would get the normal border from the block.
>
> See attached FO file for an illustration.
>
> HTH,
> Vincent
>
>
>> 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:vhennebert@gmail.com]
>> Gesendet: Dienstag, 27. Oktober 2009 16:45
>> An: fop-users@xmlgraphics.apache.org
>> 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:vhennebert@gmail.com]
>>> Gesendet: Montag, 26. Oktober 2009 11:30
>>> An: fop-users@xmlgraphics.apache.org
>>> 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: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: confusing tables again
Posted by Vincent Hennebert <vh...@gmail.com>.
Hi Georg,
Georg Datterl wrote:
> Hi Vincent,
>
> I have to admit, I did not quite understand why an invisible border, overridden by a hidden border would result in a visible border, but I think I applied your example to my table correctly. And it works, nearly.
The thing is, at the page break the table-footer is absent, so its
after-border doesn’t compete with the after-border of the table. So that
latter is chosen, which results into a present (but invisible) border.
After the page break, when the table is finished, the footer is added,
so this time its after-border specification prevails (‘hidden’ has
higher priority than any other border style) and results into a null
border. Indeed it’s the border of the outer block that will be used.
> Now the table doesn't spread over two pages in any case, but before adding the block, I have one page and after adding the block, which should actually occupy all but only the free space in the left column, the outer border moves to the next page. Without table cells, but still, the line is on the second page (see example).
>
> Then I tried to shorten this block. Shortening it by a small amount (ca. 10pt) results in the block being moved to the second page. Shortening it by a larger amount (ca. 50pt) results in the block being on the first page, but three table rows being on the second page.
I’m not sure of what you did. I didn’t see any table-footer in your
sample file. So I’ve reproduced the trick on the first file you sent in
that thread. I’ve also slightly corrected it: in the collapsing-border
model half of the border resides in the margin, so doesn’t count in the
height calculation. So to simulate the border of the outer block you
have to double its width.
To make it clear, all that trick is necessary only if you /don’t/ want
the border of the outer block replicated at each page break. Otherwise,
you can just set its conditionality to retain as explained earlier.
HTH,
Vincent
> 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:vhennebert@gmail.com]
> Gesendet: Mittwoch, 28. Oktober 2009 16:01
> An: fop-users@xmlgraphics.apache.org
> Betreff: Re: confusing tables again
>
> Hi Georg,
>
> Georg Datterl wrote:
>> 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?
>
> Yes, that would. It's so tiny, nobody would see it, would it? :-)
>
>
>> Or is there a way to creatively use colapsing borders?
>
> That's an idea. You could define an invisible (same colour as background), retained bottom border on the outer table, overridden by a hidden bottom border on an empty table footer, with table-omit-footer-at-break="true". At the page break, the footer wouldn't be there, so the table border would win and account for the block's discarded border. After the page break, the footer would nullify the border and you would get the normal border from the block.
>
> See attached FO file for an illustration.
>
> HTH,
> Vincent
>
>
>> 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:vhennebert@gmail.com]
>> Gesendet: Dienstag, 27. Oktober 2009 16:45
>> An: fop-users@xmlgraphics.apache.org
>> 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:vhennebert@gmail.com]
>>> Gesendet: Montag, 26. Oktober 2009 11:30
>>> An: fop-users@xmlgraphics.apache.org
>>> 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
AW: confusing tables again
Posted by Georg Datterl <ge...@geneon.de>.
Hi Vincent,
I have to admit, I did not quite understand why an invisible border, overridden by a hidden border would result in a visible border, but I think I applied your example to my table correctly. And it works, nearly.
Now the table doesn't spread over two pages in any case, but before adding the block, I have one page and after adding the block, which should actually occupy all but only the free space in the left column, the outer border moves to the next page. Without table cells, but still, the line is on the second page (see example).
Then I tried to shorten this block. Shortening it by a small amount (ca. 10pt) results in the block being moved to the second page. Shortening it by a larger amount (ca. 50pt) results in the block being on the first page, but three table rows being on the second page.
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:vhennebert@gmail.com]
Gesendet: Mittwoch, 28. Oktober 2009 16:01
An: fop-users@xmlgraphics.apache.org
Betreff: Re: confusing tables again
Hi Georg,
Georg Datterl wrote:
> 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?
Yes, that would. It's so tiny, nobody would see it, would it? :-)
> Or is there a way to creatively use colapsing borders?
That's an idea. You could define an invisible (same colour as background), retained bottom border on the outer table, overridden by a hidden bottom border on an empty table footer, with table-omit-footer-at-break="true". At the page break, the footer wouldn't be there, so the table border would win and account for the block's discarded border. After the page break, the footer would nullify the border and you would get the normal border from the block.
See attached FO file for an illustration.
HTH,
Vincent
> 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:vhennebert@gmail.com]
> Gesendet: Dienstag, 27. Oktober 2009 16:45
> An: fop-users@xmlgraphics.apache.org
> 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:vhennebert@gmail.com]
>> Gesendet: Montag, 26. Oktober 2009 11:30
>> An: fop-users@xmlgraphics.apache.org
>> 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
Re: confusing tables again
Posted by Vincent Hennebert <vh...@gmail.com>.
Hi Georg,
Georg Datterl wrote:
> 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?
Yes, that would. It’s so tiny, nobody would see it, would it? :-)
> Or is there a way to creatively use colapsing borders?
That’s an idea. You could define an invisible (same colour as
background), retained bottom border on the outer table, overridden by
a hidden bottom border on an empty table footer, with
table-omit-footer-at-break="true". At the page break, the footer
wouldn’t be there, so the table border would win and account for the
block’s discarded border. After the page break, the footer would nullify
the border and you would get the normal border from the block.
See attached FO file for an illustration.
HTH,
Vincent
> 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:vhennebert@gmail.com]
> Gesendet: Dienstag, 27. Oktober 2009 16:45
> An: fop-users@xmlgraphics.apache.org
> 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:vhennebert@gmail.com]
>> Gesendet: Montag, 26. Oktober 2009 11:30
>> An: fop-users@xmlgraphics.apache.org
>> 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
AW: confusing tables again
Posted by Georg Datterl <ge...@geneon.de>.
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:vhennebert@gmail.com]
Gesendet: Dienstag, 27. Oktober 2009 16:45
An: fop-users@xmlgraphics.apache.org
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:vhennebert@gmail.com]
> Gesendet: Montag, 26. Oktober 2009 11:30
> An: fop-users@xmlgraphics.apache.org
> 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: 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: confusing tables again
Posted by Vincent Hennebert <vh...@gmail.com>.
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:vhennebert@gmail.com]
> Gesendet: Montag, 26. Oktober 2009 11:30
> An: fop-users@xmlgraphics.apache.org
> 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: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
AW: confusing tables again
Posted by Georg Datterl <ge...@geneon.de>.
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. The footer image is unnecessary I guess, since it can't be included anyway (without Jeremias' extension).
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:vhennebert@gmail.com]
Gesendet: Montag, 26. Oktober 2009 11:30
An: fop-users@xmlgraphics.apache.org
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
>
> ------ 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
>
>
> ----------------------------------------------------------------------
> --
>
>
> ---------------------------------------------------------------------
> 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: confusing tables again
Posted by Vincent Hennebert <vh...@gmail.com>.
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
>
> ------ 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
>
>
> ------------------------------------------------------------------------
>
>
> ---------------------------------------------------------------------
> 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