xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vincent Hennebert <vhenneb...@gmail.com>
Subject Re: table cell duplication
Date Thu, 05 Feb 2009 11:58:34 GMT
Hi Georg,

Georg Datterl wrote:
> Hi Jost, hi Vincent
> I could use a combination of your ideas. If I just put the drawings in a table header
and fill the table body with empty cells, I still have to keep in mind that a new page means,
the header is reprinted, therefore the body moves down. Since I don't know, over how many
pages the table spans, I don't know for how many headers I should include in my calculation.

> I could generate the document with only one set of drawings. Then I would know how many
pages a table spans and I would know, how long the table body should be. Only if the last
part of the table is shorter than the drawings, the bottom line of the complete DesignTable
would move down and the page spanning of further DesignTables can be influenced. So worst
case I would have to generate the whole page-sequence once for each DesignTable. Performance
nightmare, but it should give the desired result. 

This would have to be tested, but I think you can estimate the height of
the blank content accurately enough. If you have the height of content E
and the height of pages, then you can compute the maximum number of
pages over which the DesignTable can be spread. So the maximum number of
times drawing C would appear, and substract that number of times from
the height of the blank content. That should allow you to avoid
re-generating the whole page-sequence once for every DesignTable.

By making a post-process based on the informations of the intermediate
format, you could probably manage to get the borders of the tables
inside content E extended until the bottom of the DesignTable.

> Vincent, could I just insert multiple copies of the drawings block and 
> add a break-before="page" all but the first block?

Yes, if you use the post-process approach, then you don’t need to worry
about using a table. In spite of the multiple processings problem that
you identified above, this approach may be better if you can’t
accurately estimate the height of content E.

> Georg Datterl



View raw message