xmlgraphics-fop-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Georg Datterl" <georg.datt...@geneon.de>
Subject AW: Strange table behaviour
Date Thu, 20 Aug 2009 08:34:10 GMT
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


Mime
View raw message