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
snip/
HTH,
Vincent
