[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:       2009-08-20 14:39:59
Message-ID: 4A8D603F.8080500 () gmail ! com
[Download RAW message or body]

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


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