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:[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]
