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
