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/08/10 22:50:49 UTC
Strange table behaviour
Hi everybody, it's me again and as usual, I have a fascinating little fo file for you.
Todays topic: creating blank space without padding-* or space-*, whether you want it or not.
In my fo file, I have an outer table with one cell and a bottom border. Inside I have a middle table with three rows and two columns.
Row one, cell one contains a simple block.
Row one, cell two spans all three rows and contains blocks and a table. This cell contains most of the data and should define the height of the outer table.
Row two, cell one contains a block with fixed height and a block with break-before=page. This makes the block move to the next page and break the table in row one, cell two at the height of the fixed-height block.
Row three, cell one contains a block which should sit at the foot height of the table in row one, cell two, just above the bottom line of the outer table.
Now, if it worked, I wouldn't write this. Funny thing is: Everything looks as expected, only the bottom line of the outer table is way below the bottom line of the inner table. And I don't see a reason. Maybe somebody else wants to play around with it and tell me why there's a gap.
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: Strange table behaviour
Posted by Georg Datterl <ge...@geneon.de>.
Hi Vincent,
> > My solution: I generate the the table with only one set of images and read the area tree. From the area tree I read how many pages the table takes and how much unused space I have in the left column (especially on the first page). Then I add a blank block of the gathered height in the left column, then a copy of the images with a break-before, then another blank block of (pageheight-imagesheight), another set of images and so on until the table is complete. The images always start on a new page und the blank block prevents the data in the right column from breaking too soon.
> But if the blank blocks have a height of (page height − images height), then the forced break isn’t necessary, is it? It’s basically that forced break that is the cause of your problems, so if you can find a solution without it, that should work well.
That's true for the second page. On the first page, the height of the blank block is right-column height - image height. If the right table breaks early (because of a keep-together that keeps the last three table lines togehter with a following image), the blank block spreads to the table break, but without the break-before the image (being smaller than 3 table-lines + following image) still fits on the first page. So I changed my code and add a blank block with a keep-with-previous on each page including the last one. Even if the table breaks early, the blank block pulls the image to the next page. Up to now that seems to work fine.
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, 13. August 2009 13:01
An: fop-users@xmlgraphics.apache.org
Betreff: Re: Strange table behaviour
Hi Georg,
Georg Datterl wrote:
> Hi Vincent,
>
> I'll try the start-indent solution.
>
> As for the block and the break, we were discussing that in earlier threads (around February). I have a layout with text and table in the right column and images in the left column. If the right column breaks to a new page (or pages), the images should be reprinted on that page, too.
>
> My solution: I generate the the table with only one set of images and read the area tree. From the area tree I read how many pages the table takes and how much unused space I have in the left column (especially on the first page). Then I add a blank block of the gathered height in the left column, then a copy of the images with a break-before, then another blank block of (pageheight-imagesheight), another set of images and so on until the table is complete. The images always start on a new page und the blank block prevents the data in the right column from breaking too soon.
But if the blank blocks have a height of (page height − images height), then the forced break isn’t necessary, is it? It’s basically that forced break that is the cause of your problems, so if you can find a solution without it, that should work well.
<snip/>
HTH,
Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Strange table behaviour
Posted by Vincent Hennebert <vh...@gmail.com>.
Hi Georg,
Georg Datterl wrote:
> Hi Vincent,
>
> Please forget the previous question. I have finally reached the point where it is obvious my solution does not work. Changing one parameter to make a testcase work breaks another testcase and vice versa. Now: New solution! As you mentioned in one posting, I now split the table. As before, I generate the whole table first (with an id on each row) and then query the area tree for the first id on each page. then I split the table at this lines to get one table per page. Each table gets its own cell in the outer table and a corresponding cell for the drawings. Takes a bit more time to process, but easier to understand.
Sounds like a good idea. You were really starting to push FOP to its
limit anyway ;-)
It’s certainly possible to figure out what that magic number corresponds
to, but that would require a thorough study of FOP’s behaviour in
a debugging session. Given the complexity of the file, the table in
a table, and that the way the table algorithm works is all but
intuitive, that would eat a looot of energy.
So I’m glad you found another solution ;-)
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: Georg Datterl [mailto:georg.datterl@geneon.de]
> Gesendet: Montag, 18. Januar 2010 14:54
> An: fop-users@xmlgraphics.apache.org
> Betreff: AW: Strange table behaviour
>
> Hi Vincent,
>
> Remember this thread?
>
>>> Well, if I don't have a blank block in the left column, everything works fine.
>>> I guess, I could reduce the height of the blank block by the height
>>> of the table header, which I could get by adding an id attribute to the table-header entry.
>> That was going to be my suggestion, which worked well on a simplified
>> version of your file, but on the real file it appears that you have to
>> reduce it by more than that (around 60pt, as I found out). I don't know why, I must say.
>
> As a reminder and introduction for those who ignored my postings at that time, let me give a short introduction:
> I have a two-column outer table with a long inner table in the right column. This table spreads over (at least) three pages. For this problem here we only need to look at the last two pages.
> The left column contains (on the last two pages)in one row an image, a blank block, another image and another blank block. The next (and last) row contains a text, which should always be at the end of the cell, just above the bottom line of the outer table. The second image should be on the last page, therefore the first blank block needs a special height to push the image to the next page. We would expect the height of the blank block to be "height of page - height of image", but as we found out, the block needs to be "height of page - height of image - a magic number, depending on page length". So far nothing new.
>
> My new problem is: If "image height + height of the second blank block + height of the text" is less than the magic number, the whole content of the last page moves to the previous page. Logical, but not desired.
>
> *) adding a break to the second image or the first blank block changes the way the layout algorithm works and gives undesired results.
> *) decreasing the magic number changes the location of the page break in the inner table, which makes the height of the blank blocks invalid
>
> My present solution is, I increase the height of the second blank block to reach a total height greater than the magic number. That works, but leads to blank space in both columns which is not nice.
>
> Do you (does anbody?) know a way to keep the text, second image and second block on the last page without upseting the table layout algorithm?
>
> 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, 20. August 2009 16:40
> An: fop-users@xmlgraphics.apache.org
> Betreff: Re: Strange table behaviour
>
> Hi Georg,
>
> Georg Datterl wrote:
>> Hi Vincent,
>>
>>> Entering the details would be too complicated, but the problem is basically due to the repeated header of the inner table at page breaks.
>> Well, if I don't have a blank block in the left column, everything works fine. I guess, I could reduce the height of the blank block by the height of the table header, which I could get by adding an id attribute to the table-header entry.
>
> That was going to be my suggestion, which worked well on a simplified version of your file, but on the real file it appears that you have to reduce it by more than that (around 60pt, as I found out). I don't know why, I must say.
>
>
>> Then my problem would be, what if the image is smaller than the table header? In that case, the image would move from page 3 to page 2, I assume. A break-after at the blank block would lead to same problems I had before.
>
> If you put a keep-with-next on the block containing the image you should hopefully avoid that situation in most cases.
>
>
>> Would it theoretically help, if I get the table header height, subtract it from the blank block height and add it as space-before to the image?
>> It would be easier than finding the number of rows in the table and splitting the table in two, although that should be possible too, somehow.
>>
>>> You put the red marker as a child of the block that surrounds the
>>> whole content of the spanning cell, and the green marker inside the
>>> cell on row 3, column 1. Both end at roughly the same moment when the
>>> end of the surrounding table is reached.
>>> They are 'competing' when the marker is retrieved and it appears that
>>> the red one wins. If you put the green marker in an empty block after
>>> the big surrounding block that contains the red one, that should
>>> work.
>> So the end of the block is interesting too? I thought, only the
>> beginning. So here
>>
>> <block>
>> <marker1 />
>> <block>
>> <marker2 />
>> </block>
>> </block>
>> <retrieve-marker last>
>>
>> would find marker1?
>
> Markers are attached to every area generated by the block, not only the first one. The problem here is that on the third page there is a competition between two markers originating from two different columns of the table. It appears that it's the red one that is selected. I would have to look at the spec in more details, but maybe that behaviour violates it.
> A way to avoid that competition is to put all the markers in the same column. That way you retrieve the well-defined case illustrated in your example above (in which marker2 would be selected).
>
> <snip/>
>
> Vincent
>
> ---------------------------------------------------------------------
> 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
>
>
> ---------------------------------------------------------------------
> 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: Strange table behaviour
Posted by Georg Datterl <ge...@geneon.de>.
Hi Vincent,
Please forget the previous question. I have finally reached the point where it is obvious my solution does not work. Changing one parameter to make a testcase work breaks another testcase and vice versa. Now: New solution! As you mentioned in one posting, I now split the table. As before, I generate the whole table first (with an id on each row) and then query the area tree for the first id on each page. then I split the table at this lines to get one table per page. Each table gets its own cell in the outer table and a corresponding cell for the drawings. Takes a bit more time to process, but easier to understand.
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: Montag, 18. Januar 2010 14:54
An: fop-users@xmlgraphics.apache.org
Betreff: AW: Strange table behaviour
Hi Vincent,
Remember this thread?
> > Well, if I don't have a blank block in the left column, everything works fine.
> > I guess, I could reduce the height of the blank block by the height
> > of the table header, which I could get by adding an id attribute to the table-header entry.
> That was going to be my suggestion, which worked well on a simplified
> version of your file, but on the real file it appears that you have to
> reduce it by more than that (around 60pt, as I found out). I don't know why, I must say.
As a reminder and introduction for those who ignored my postings at that time, let me give a short introduction:
I have a two-column outer table with a long inner table in the right column. This table spreads over (at least) three pages. For this problem here we only need to look at the last two pages.
The left column contains (on the last two pages)in one row an image, a blank block, another image and another blank block. The next (and last) row contains a text, which should always be at the end of the cell, just above the bottom line of the outer table. The second image should be on the last page, therefore the first blank block needs a special height to push the image to the next page. We would expect the height of the blank block to be "height of page - height of image", but as we found out, the block needs to be "height of page - height of image - a magic number, depending on page length". So far nothing new.
My new problem is: If "image height + height of the second blank block + height of the text" is less than the magic number, the whole content of the last page moves to the previous page. Logical, but not desired.
*) adding a break to the second image or the first blank block changes the way the layout algorithm works and gives undesired results.
*) decreasing the magic number changes the location of the page break in the inner table, which makes the height of the blank blocks invalid
My present solution is, I increase the height of the second blank block to reach a total height greater than the magic number. That works, but leads to blank space in both columns which is not nice.
Do you (does anbody?) know a way to keep the text, second image and second block on the last page without upseting the table layout algorithm?
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, 20. August 2009 16:40
An: fop-users@xmlgraphics.apache.org
Betreff: Re: Strange table behaviour
Hi Georg,
Georg Datterl wrote:
> Hi Vincent,
>
>> Entering the details would be too complicated, but the problem is basically due to the repeated header of the inner table at page breaks.
>
> Well, if I don't have a blank block in the left column, everything works fine. I guess, I could reduce the height of the blank block by the height of the table header, which I could get by adding an id attribute to the table-header entry.
That was going to be my suggestion, which worked well on a simplified version of your file, but on the real file it appears that you have to reduce it by more than that (around 60pt, as I found out). I don't know why, I must say.
> Then my problem would be, what if the image is smaller than the table header? In that case, the image would move from page 3 to page 2, I assume. A break-after at the blank block would lead to same problems I had before.
If you put a keep-with-next on the block containing the image you should hopefully avoid that situation in most cases.
> Would it theoretically help, if I get the table header height, subtract it from the blank block height and add it as space-before to the image?
> It would be easier than finding the number of rows in the table and splitting the table in two, although that should be possible too, somehow.
>
>> You put the red marker as a child of the block that surrounds the
>> whole content of the spanning cell, and the green marker inside the
>> cell on row 3, column 1. Both end at roughly the same moment when the
>> end of the surrounding table is reached.
>> They are 'competing' when the marker is retrieved and it appears that
>> the red one wins. If you put the green marker in an empty block after
>> the big surrounding block that contains the red one, that should
>> work.
>
> So the end of the block is interesting too? I thought, only the
> beginning. So here
>
> <block>
> <marker1 />
> <block>
> <marker2 />
> </block>
> </block>
> <retrieve-marker last>
>
> would find marker1?
Markers are attached to every area generated by the block, not only the first one. The problem here is that on the third page there is a competition between two markers originating from two different columns of the table. It appears that it's the red one that is selected. I would have to look at the spec in more details, but maybe that behaviour violates it.
A way to avoid that competition is to put all the markers in the same column. That way you retrieve the well-defined case illustrated in your example above (in which marker2 would be selected).
<snip/>
Vincent
---------------------------------------------------------------------
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
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
AW: Strange table behaviour
Posted by Georg Datterl <ge...@geneon.de>.
Hi Vincent,
Remember this thread?
> > Well, if I don't have a blank block in the left column, everything works fine.
> > I guess, I could reduce the height of the blank block by the height of the
> > table header, which I could get by adding an id attribute to the table-header entry.
> That was going to be my suggestion, which worked well on a simplified version of your
> file, but on the real file it appears that you have to reduce it by more than that
> (around 60pt, as I found out). I don't know why, I must say.
As a reminder and introduction for those who ignored my postings at that time, let me give a short introduction:
I have a two-column outer table with a long inner table in the right column. This table spreads over (at least) three pages. For this problem here we only need to look at the last two pages.
The left column contains (on the last two pages)in one row an image, a blank block, another image and another blank block. The next (and last) row contains a text, which should always be at the end of the cell, just above the bottom line of the outer table. The second image should be on the last page, therefore the first blank block needs a special height to push the image to the next page. We would expect the height of the blank block to be "height of page - height of image", but as we found out, the block needs to be "height of page - height of image - a magic number, depending on page length". So far nothing new.
My new problem is: If "image height + height of the second blank block + height of the text" is less than the magic number, the whole content of the last page moves to the previous page. Logical, but not desired.
*) adding a break to the second image or the first blank block changes the way the layout algorithm works and gives undesired results.
*) decreasing the magic number changes the location of the page break in the inner table, which makes the height of the blank blocks invalid
My present solution is, I increase the height of the second blank block to reach a total height greater than the magic number. That works, but leads to blank space in both columns which is not nice.
Do you (does anbody?) know a way to keep the text, second image and second block on the last page without upseting the table layout algorithm?
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, 20. August 2009 16:40
An: fop-users@xmlgraphics.apache.org
Betreff: Re: Strange table behaviour
Hi Georg,
Georg Datterl wrote:
> Hi Vincent,
>
>> Entering the details would be too complicated, but the problem is basically due to the repeated header of the inner table at page breaks.
>
> Well, if I don't have a blank block in the left column, everything works fine. I guess, I could reduce the height of the blank block by the height of the table header, which I could get by adding an id attribute to the table-header entry.
That was going to be my suggestion, which worked well on a simplified version of your file, but on the real file it appears that you have to reduce it by more than that (around 60pt, as I found out). I don't know why, I must say.
> Then my problem would be, what if the image is smaller than the table header? In that case, the image would move from page 3 to page 2, I assume. A break-after at the blank block would lead to same problems I had before.
If you put a keep-with-next on the block containing the image you should hopefully avoid that situation in most cases.
> Would it theoretically help, if I get the table header height, subtract it from the blank block height and add it as space-before to the image?
> It would be easier than finding the number of rows in the table and splitting the table in two, although that should be possible too, somehow.
>
>> You put the red marker as a child of the block that surrounds the
>> whole content of the spanning cell, and the green marker inside the
>> cell on row 3, column 1. Both end at roughly the same moment when the
>> end of the surrounding table is reached.
>> They are 'competing' when the marker is retrieved and it appears that
>> the red one wins. If you put the green marker in an empty block after
>> the big surrounding block that contains the red one, that should
>> work.
>
> So the end of the block is interesting too? I thought, only the
> beginning. So here
>
> <block>
> <marker1 />
> <block>
> <marker2 />
> </block>
> </block>
> <retrieve-marker last>
>
> would find marker1?
Markers are attached to every area generated by the block, not only the first one. The problem here is that on the third page there is a competition between two markers originating from two different columns of the table. It appears that it's the red one that is selected. I would have to look at the spec in more details, but maybe that behaviour violates it.
A way to avoid that competition is to put all the markers in the same column. That way you retrieve the well-defined case illustrated in your example above (in which marker2 would be selected).
<snip/>
Vincent
---------------------------------------------------------------------
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: Strange table behaviour
Posted by Vincent Hennebert <vh...@gmail.com>.
Hi Georg,
Georg Datterl wrote:
> Hi Vincent,
>
>> Entering the details would be too complicated, but the problem is basically due to the repeated header of the inner table at page breaks.
>
> Well, if I don't have a blank block in the left column, everything works fine. I guess, I could reduce the height of the blank block by the height of the table header, which I could get by adding an id attribute to the table-header entry.
That was going to be my suggestion, which worked well on a simplified
version of your file, but on the real file it appears that you have to
reduce it by more than that (around 60pt, as I found out). I don’t know
why, I must say.
> Then my problem would be, what if the image is smaller than the table header? In that case, the image would move from page 3 to page 2, I assume. A break-after at the blank block would lead to same problems I had before.
If you put a keep-with-next on the block containing the image you should
hopefully avoid that situation in most cases.
> Would it theoretically help, if I get the table header height, subtract it from the blank block height and add it as space-before to the image?
> It would be easier than finding the number of rows in the table and splitting the table in two, although that should be possible too, somehow.
>
>> You put the red marker as a child of the block that surrounds
>> the whole content of the spanning cell, and the green marker
>> inside the cell on row 3, column 1. Both end at roughly the
>> same moment when the end of the surrounding table is reached.
>> They are 'competing' when the marker is retrieved and it
>> appears that the red one wins. If you put the green marker
>> in an empty block after the big surrounding block that
>> contains the red one, that should work.
>
> So the end of the block is interesting too? I thought, only the beginning. So here
>
> <block>
> <marker1 />
> <block>
> <marker2 />
> </block>
> </block>
> <retrieve-marker last>
>
> would find marker1?
Markers are attached to every area generated by the block, not only the
first one. The problem here is that on the third page there is a
competition between two markers originating from two different columns
of the table. It appears that it’s the red one that is selected. I would
have to look at the spec in more details, but maybe that behaviour
violates it.
A way to avoid that competition is to put all the markers in the same
column. That way you retrieve the well-defined case illustrated in your
example above (in which marker2 would be selected).
<snip/>
Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
AW: Strange table behaviour
Posted by Georg Datterl <ge...@geneon.de>.
Hi Vincent,
> Entering the details would be too complicated, but the problem is basically due to the repeated header of the inner table at page breaks.
Well, if I don't have a blank block in the left column, everything works fine. I guess, I could reduce the height of the blank block by the height of the table header, which I could get by adding an id attribute to the table-header entry. Then my problem would be, what if the image is smaller than the table header? In that case, the image would move from page 3 to page 2, I assume. A break-after at the blank block would lead to same problems I had before.
Would it theoretically help, if I get the table header height, subtract it from the blank block height and add it as space-before to the image?
It would be easier than finding the number of rows in the table and splitting the table in two, although that should be possible too, somehow.
> You put the red marker as a child of the block that surrounds
> the whole content of the spanning cell, and the green marker
> inside the cell on row 3, column 1. Both end at roughly the
> same moment when the end of the surrounding table is reached.
> They are 'competing' when the marker is retrieved and it
> appears that the red one wins. If you put the green marker
> in an empty block after the big surrounding block that
> contains the red one, that should work.
So the end of the block is interesting too? I thought, only the beginning. So here
<block>
<marker1 />
<block>
<marker2 />
</block>
</block>
<retrieve-marker last>
would find marker1?
Mit freundlichen Grüßen
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, 19. August 2009 18:55
An: fop-users@xmlgraphics.apache.org
Betreff: Re: Strange table behaviour
Hi Georg,
Georg Datterl wrote:
> Hi Vincent,
>
> I tried your suggestion and it works nearly perfectly. Maybe you can take another look at the resulting fo and answer me two questions:
>
> * Why is the table breaking incorrectly on the second page? The table is painting into the footer area (which starts at the red marker), but judging from the gap on page three, it seems like the break was correct when generating the area tree, so the addition of the pink blank block seems to influence the break rules. Reducing the height of the blank block does influence the break, but i have to reduce the blank block by around 100pt to get a correct break in the table.
You are hitting FOP's fundamental limitation about tables. The table algorithm works well only when the table is broken over maximum two pages. Beyond that there can be glitches as the one you see on your document. You may want to have a look at the following page for an illustration of the process (although it's targeted at developers):
http://wiki.apache.org/xmlgraphics-fop/TableLayout/KnownProblems
Entering the details would be too complicated, but the problem is basically due to the repeated header of the inner table at page breaks.
The algorithm doesn't realise that space must be accounted for it on the second page. See it like this: the algorithm assumes that the table will be broken at most twice, so the header will appear at most twice. But actually the table is broken 3 times, so the header must appear
3 times... which is not handled. This is a simplified view but roughly corresponds to what happens.
One workaround could be to split the table into several sub-tables that would fit on two pages. Since you're working with the area tree, you could detect that the table is split in 3, and put the 3rt part into a new table. Not sure how feasible that would be though :-\
> * I want a "table continues on next page" marker for the whole image/table construct. So I set a (for this example) red marker at the beginning of the text block (second column, the magenta colored ones) and a green marker at the beginning of the PF-number block (first column, red blocks), because I always have text and the PF-Number always has to be on the last page. I'm quite sure I should get a red marker on the first page, because I have a magenta block after a red block, obviously I get a red marker on the second page, although there's neither a magenta nor a red block, but I'm positive I don't like the red block on the last page. I guess I can solve that problem by placing the marker differently, but I'd like to understand what happens here.
You put the red marker as a child of the block that surrounds the whole content of the spanning cell, and the green marker inside the cell on row 3, column 1. Both end at roughly the same moment when the end of the surrounding table is reached. They are 'competing' when the marker is retrieved and it appears that the red one wins. If you put the green marker in an empty block after the big surrounding block that contains the red one, that should work.
> So, if you are not too busy, I'd be gratefull for some more input.
>
> Regards,
>
> Georg Datterl
<snip/>
HTH,
Vincent
---------------------------------------------------------------------
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: Strange table behaviour
Posted by Vincent Hennebert <vh...@gmail.com>.
Hi Georg,
Georg Datterl wrote:
> Hi Vincent,
>
> I tried your suggestion and it works nearly perfectly. Maybe you can take another look at the resulting fo and answer me two questions:
>
> * Why is the table breaking incorrectly on the second page? The table is painting into the footer area (which starts at the red marker), but judging from the gap on page three, it seems like the break was correct when generating the area tree, so the addition of the pink blank block seems to influence the break rules. Reducing the height of the blank block does influence the break, but i have to reduce the blank block by around 100pt to get a correct break in the table.
You are hitting FOP’s fundamental limitation about tables. The table
algorithm works well only when the table is broken over maximum two
pages. Beyond that there can be glitches as the one you see on your
document. You may want to have a look at the following page for an
illustration of the process (although it’s targeted at developers):
http://wiki.apache.org/xmlgraphics-fop/TableLayout/KnownProblems
Entering the details would be too complicated, but the problem is
basically due to the repeated header of the inner table at page breaks.
The algorithm doesn’t realise that space must be accounted for it on the
second page. See it like this: the algorithm assumes that the table will
be broken at most twice, so the header will appear at most twice. But
actually the table is broken 3 times, so the header must appear
3 times... which is not handled. This is a simplified view but roughly
corresponds to what happens.
One workaround could be to split the table into several sub-tables that
would fit on two pages. Since you’re working with the area tree, you
could detect that the table is split in 3, and put the 3rt part into
a new table. Not sure how feasible that would be though :-\
> * I want a "table continues on next page" marker for the whole image/table construct. So I set a (for this example) red marker at the beginning of the text block (second column, the magenta colored ones) and a green marker at the beginning of the PF-number block (first column, red blocks), because I always have text and the PF-Number always has to be on the last page. I'm quite sure I should get a red marker on the first page, because I have a magenta block after a red block, obviously I get a red marker on the second page, although there's neither a magenta nor a red block, but I'm positive I don't like the red block on the last page. I guess I can solve that problem by placing the marker differently, but I'd like to understand what happens here.
You put the red marker as a child of the block that surrounds the whole
content of the spanning cell, and the green marker inside the cell on
row 3, column 1. Both end at roughly the same moment when the end of the
surrounding table is reached. They are ‘competing’ when the marker is
retrieved and it appears that the red one wins. If you put the green
marker in an empty block after the big surrounding block that contains
the red one, that should work.
> So, if you are not too busy, I'd be gratefull for some more input.
>
> Regards,
>
> Georg Datterl
<snip/>
HTH,
Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
AW: Strange table behaviour
Posted by Georg Datterl <ge...@geneon.de>.
Hi Vincent,
I tried your suggestion and it works nearly perfectly. Maybe you can take another look at the resulting fo and answer me two questions:
* Why is the table breaking incorrectly on the second page? The table is painting into the footer area (which starts at the red marker), but judging from the gap on page three, it seems like the break was correct when generating the area tree, so the addition of the pink blank block seems to influence the break rules. Reducing the height of the blank block does influence the break, but i have to reduce the blank block by around 100pt to get a correct break in the table.
* I want a "table continues on next page" marker for the whole image/table construct. So I set a (for this example) red marker at the beginning of the text block (second column, the magenta colored ones) and a green marker at the beginning of the PF-number block (first column, red blocks), because I always have text and the PF-Number always has to be on the last page. I'm quite sure I should get a red marker on the first page, because I have a magenta block after a red block, obviously I get a red marker on the second page, although there's neither a magenta nor a red block, but I'm positive I don't like the red block on the last page. I guess I can solve that problem by placing the marker differently, but I'd like to understand what happens here.
So, if you are not too busy, I'd be gratefull for some more input.
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, 13. August 2009 13:01
An: fop-users@xmlgraphics.apache.org
Betreff: Re: Strange table behaviour
Hi Georg,
Georg Datterl wrote:
> Hi Vincent,
>
> I'll try the start-indent solution.
>
> As for the block and the break, we were discussing that in earlier threads (around February). I have a layout with text and table in the right column and images in the left column. If the right column breaks to a new page (or pages), the images should be reprinted on that page, too.
>
> My solution: I generate the the table with only one set of images and read the area tree. From the area tree I read how many pages the table takes and how much unused space I have in the left column (especially on the first page). Then I add a blank block of the gathered height in the left column, then a copy of the images with a break-before, then another blank block of (pageheight-imagesheight), another set of images and so on until the table is complete. The images always start on a new page und the blank block prevents the data in the right column from breaking too soon.
But if the blank blocks have a height of (page height − images height), then the forced break isn’t necessary, is it? It’s basically that forced break that is the cause of your problems, so if you can find a solution without it, that should work well.
<snip/>
HTH,
Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Strange table behaviour
Posted by Vincent Hennebert <vh...@gmail.com>.
Hi Georg,
Georg Datterl wrote:
> Hi Vincent,
>
> I'll try the start-indent solution.
>
> As for the block and the break, we were discussing that in earlier threads (around February). I have a layout with text and table in the right column and images in the left column. If the right column breaks to a new page (or pages), the images should be reprinted on that page, too.
>
> My solution: I generate the the table with only one set of images and read the area tree. From the area tree I read how many pages the table takes and how much unused space I have in the left column (especially on the first page). Then I add a blank block of the gathered height in the left column, then a copy of the images with a break-before, then another blank block of (pageheight-imagesheight), another set of images and so on until the table is complete. The images always start on a new page und the blank block prevents the data in the right column from breaking too soon.
But if the blank blocks have a height of (page height − images height),
then the forced break isn’t necessary, is it? It’s basically that forced
break that is the cause of your problems, so if you can find a solution
without it, that should work well.
<snip/>
HTH,
Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
AW: Strange table behaviour
Posted by Georg Datterl <ge...@geneon.de>.
Hi Vincent,
I'll try the start-indent solution.
As for the block and the break, we were discussing that in earlier threads (around February). I have a layout with text and table in the right column and images in the left column. If the right column breaks to a new page (or pages), the images should be reprinted on that page, too.
My solution: I generate the the table with only one set of images and read the area tree. From the area tree I read how many pages the table takes and how much unused space I have in the left column (especially on the first page). Then I add a blank block of the gathered height in the left column, then a copy of the images with a break-before, then another blank block of (pageheight-imagesheight), another set of images and so on until the table is complete. The images always start on a new page und the blank block prevents the data in the right column from breaking too soon.
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, 12. August 2009 12:16
An: fop-users@xmlgraphics.apache.org
Betreff: Re: Strange table behaviour
Hi Georg,
Georg Datterl wrote:
> Hi Vincent,
>
> Sometimes it seemd like a space-after property was ignored in the table (because it was at the start of the page) but not ignored in the calculation of the table height. But I am not sure, since other changes changed the behaviour as well.
That shouldn't happen. The handling of conditional before- or after-spaces was fixed 2 years ago.
> The outer table is a simple table with three columns used to align the inner table.
>
> <fo:table-column
> column-number="1"
>
> column-width="proportional-column-width("+(horizontalAlignment==ALIGN_RIGHT ||horizontalAlignment==ALIGN_CENTER?1:0)+") /> <fo:table-column
> column-number="2"
>
> column-width="+(percent||contentWidth<0?"99%":(format(contentWidth)+"pt"))+" /> <fo:table-column
> column-number="3"
>
> column-width="proportional-column-width("+(horizontalAlignment==ALIGN_
> LEFT||horizontalAlignment==ALIGN_CENTER?0:1)+") />
>
> If there's a better way, I might get rid of the table.
The start-indent property may do the job for you. Assuming the table must be 200pt wide:
- if the table must be left-aligned: nothing to do;
- if it must be centred: start-indent="50% - 100pt"
- if it must be right-aligned: start-indent="100% - 200pt"
Be sure to reset start-indent to 0, on the table-body for example.
Otherwise it will be propagated to the children elements.
You may want to explain in more details what it is exactly that you want to achieve with your break-before and 76.144pt high block in the second row. We may be able to come up with alternative solutions.
<snip/>
HTH,
Vincent
---------------------------------------------------------------------
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: Strange table behaviour
Posted by Vincent Hennebert <vh...@gmail.com>.
Hi Georg,
Georg Datterl wrote:
> Hi Vincent,
>
> Sometimes it seemd like a space-after property was ignored in the table (because it was at the start of the page) but not ignored in the calculation of the table height. But I am not sure, since other changes changed the behaviour as well.
That shouldn’t happen. The handling of conditional before- or
after-spaces was fixed 2 years ago.
> The outer table is a simple table with three columns used to align the inner table.
>
> <fo:table-column
> column-number="1"
> column-width="proportional-column-width("+(horizontalAlignment==ALIGN_RIGHT ||horizontalAlignment==ALIGN_CENTER?1:0)+") />
> <fo:table-column
> column-number="2"
> column-width="+(percent||contentWidth<0?"99%":(format(contentWidth)+"pt"))+" />
> <fo:table-column
> column-number="3"
> column-width="proportional-column-width("+(horizontalAlignment==ALIGN_LEFT||horizontalAlignment==ALIGN_CENTER?0:1)+") />
>
> If there's a better way, I might get rid of the table.
The start-indent property may do the job for you. Assuming the table
must be 200pt wide:
- if the table must be left-aligned: nothing to do;
- if it must be centred: start-indent="50% - 100pt"
- if it must be right-aligned: start-indent="100% - 200pt"
Be sure to reset start-indent to 0, on the table-body for example.
Otherwise it will be propagated to the children elements.
You may want to explain in more details what it is exactly that you want
to achieve with your break-before and 76.144pt high block in the second
row. We may be able to come up with alternative solutions.
<snip/>
HTH,
Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
AW: Strange table behaviour
Posted by Georg Datterl <ge...@geneon.de>.
Hi Vincent,
Sometimes it seemd like a space-after property was ignored in the table (because it was at the start of the page) but not ignored in the calculation of the table height. But I am not sure, since other changes changed the behaviour as well.
The outer table is a simple table with three columns used to align the inner table.
<fo:table-column
column-number="1"
column-width="proportional-column-width("+(horizontalAlignment==ALIGN_RIGHT ||horizontalAlignment==ALIGN_CENTER?1:0)+") />
<fo:table-column
column-number="2"
column-width="+(percent||contentWidth<0?"99%":(format(contentWidth)+"pt"))+" />
<fo:table-column
column-number="3"
column-width="proportional-column-width("+(horizontalAlignment==ALIGN_LEFT||horizontalAlignment==ALIGN_CENTER?0:1)+") />
If there's a better way, I might get rid of the table.
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, 11. August 2009 13:30
An: fop-users@xmlgraphics.apache.org
Betreff: Re: Strange table behaviour
Hi Georg,
Georg Datterl wrote:
> Hi everybody, it's me again and as usual, I have a fascinating little fo file for you.
Fascinating... Indeed...
> Todays topic: creating blank space without padding-* or space-*, whether you want it or not.
> In my fo file, I have an outer table with one cell and a bottom border. Inside I have a middle table with three rows and two columns.
> Row one, cell one contains a simple block.
> Row one, cell two spans all three rows and contains blocks and a table. This cell contains most of the data and should define the height of the outer table.
> Row two, cell one contains a block with fixed height and a block with break-before=page. This makes the block move to the next page and break the table in row one, cell two at the height of the fixed-height block.
> Row three, cell one contains a block which should sit at the foot height of the table in row one, cell two, just above the bottom line of the outer table.
>
> Now, if it worked, I wouldn't write this. Funny thing is: Everything looks as expected, only the bottom line of the outer table is way below the bottom line of the inner table. And I don't see a reason. Maybe somebody else wants to play around with it and tell me why there's a gap.
I'm not going to enter the details, but there seems to be a flaw in the algorithm that deals with tables. There are many weird situations that can occur with tables, and the algorithm tries to account for all of them, and it basically fails at that. Basic cases are simple, but when you introduce forced breaks, fixed row heights, row-spanning cells, etc., you quickly reach the limits of the approach.
I attached to this message a version of your FO file that I simplified in order to ease debugging. The following computations have been made based on that file.
Basically, at the page break, the algorithm believes that there is more of the second column to lay out on the second page than is actually the case.
If there were no forced break, the whole table would fit on a single page, and the rows would resp. have the following heights: 10pt, 86pt, 90pt.
But there is a forced break. But the second column can't be broken before the first cell of the inner table. So all that content (112.5pt) must be put on the first page. Which makes the first row have a height of 10pt, and the second row a height of 102.5pt on the first page, and 10pt on the second page. There are 73.5pt of content from the second column to be put on the second page, so the third row will grow accordingly to 73.5pt minus the height of the second row, so 63.5pt...
But the algorithm will still make it 90pt high. Hence the additional white space at the bottom of the table cell.
If you remove the surrounding table the problem disappears, but I guess you have a good reason for it being there. I have no other workaround in mind at the moment, but I'll try to think about that.
Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Strange table behaviour
Posted by Vincent Hennebert <vh...@gmail.com>.
Hi Georg,
Georg Datterl wrote:
> Hi everybody, it's me again and as usual, I have a fascinating little fo file for you.
Fascinating... Indeed...
> Todays topic: creating blank space without padding-* or space-*, whether you want it or not.
> In my fo file, I have an outer table with one cell and a bottom border. Inside I have a middle table with three rows and two columns.
> Row one, cell one contains a simple block.
> Row one, cell two spans all three rows and contains blocks and a table. This cell contains most of the data and should define the height of the outer table.
> Row two, cell one contains a block with fixed height and a block with break-before=page. This makes the block move to the next page and break the table in row one, cell two at the height of the fixed-height block.
> Row three, cell one contains a block which should sit at the foot height of the table in row one, cell two, just above the bottom line of the outer table.
>
> Now, if it worked, I wouldn't write this. Funny thing is: Everything looks as expected, only the bottom line of the outer table is way below the bottom line of the inner table. And I don't see a reason. Maybe somebody else wants to play around with it and tell me why there's a gap.
I’m not going to enter the details, but there seems to be a flaw in the
algorithm that deals with tables. There are many weird situations that
can occur with tables, and the algorithm tries to account for all of
them, and it basically fails at that. Basic cases are simple, but when
you introduce forced breaks, fixed row heights, row-spanning cells,
etc., you quickly reach the limits of the approach.
I attached to this message a version of your FO file that I simplified
in order to ease debugging. The following computations have been made
based on that file.
Basically, at the page break, the algorithm believes that there is more
of the second column to lay out on the second page than is actually the
case.
If there were no forced break, the whole table would fit on a single
page, and the rows would resp. have the following heights: 10pt, 86pt,
90pt.
But there is a forced break. But the second column can’t be broken
before the first cell of the inner table. So all that content (112.5pt)
must be put on the first page. Which makes the first row have a height
of 10pt, and the second row a height of 102.5pt on the first page, and
10pt on the second page. There are 73.5pt of content from the second
column to be put on the second page, so the third row will grow
accordingly to 73.5pt minus the height of the second row, so 63.5pt...
But the algorithm will still make it 90pt high. Hence the additional
white space at the bottom of the table cell.
If you remove the surrounding table the problem disappears, but I guess
you have a good reason for it being there. I have no other workaround in
mind at the moment, but I’ll try to think about that.
Vincent