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:[email protected]] > Gesendet: Montag, 18. Januar 2010 14:54 > An: [email protected] > 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:[email protected]] > Gesendet: Donnerstag, 20. August 2009 16:40 > An: [email protected] > 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: [email protected] > For additional commands, e-mail: [email protected] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
