[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fop-user
Subject:    Re: Strange table behaviour
From:       Vincent Hennebert <vhennebert () gmail ! com>
Date:       2010-01-21 17:11:47
Message-ID: 4B588AD3.2040309 () gmail ! com
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]