> -----Original Message-----
> From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
>
> On 27.04.2005 18:28:55 Andreas L. Delmelle wrote:
> <snip />
> > BTW: Does this problem pose itself only if a single cell
> > or row spans more than two pages, or also when an entire
> > row-group does so?
>
> Possibly, yes. A row-group in this context is formed because at least
> one cell has row-spanning. Therefore, you have the possibility that a
> cell span over more than 2 pages.
>
I was just wondering what that would mean for the following, admittedly
somewhat unrealistic example, more like 'abstract layout art'... Well, a
sketch anyway :-)
<fo:table>
...
<fo:table-body>
<fo:table-row>
<fo:table-cell number-rows-spanned="2" column-number="1">
<!-- block content -->
</fo:table-cell>
<fo:table-cell column-number="2">
<!-- block content -->
</fo:table-cell>
<fo:table-cell column-number="3">
<!-- block content -->
</fo:table-cell>
</fo:table-row>
<fo:table-row>
<fo:table-cell number-rows-spanned="2" column-number="2">
<!-- block content -->
</fo:table-cell>
<fo:table-cell column-number="3">
<!-- block content -->
</fo:table-cell>
</fo:table-row>
<fo:table-row>
<fo:table-cell column-number="1">
<!-- block content -->
</fo:table-cell>
<fo:table-cell number-rows-spanned="2" column-number="3">
<!-- block content -->
</fo:table-cell>
</fo:table-row>
<fo:table-row>
<fo:table-cell number-rows-spanned="2" column-number="1">
<!-- block content -->
</fo:table-cell>
<fo:table-cell column-number="2">
<!-- block content -->
</fo:table-cell>
</fo:table-row>
<!-- repeat last three of above rows, and add
a last row filling the cells in the
unoccupied columns -->
</fo:table-body>
</fo:table>
IIUC, this borderline case would result in the entire table basically being
one row-group (? In every row there is always one cell spanning from the
previous row as well as another cell spanning to the next)
The cells themselves won't necessarily span multiple pages, neither will the
rows... but it does make a nice demonstration of why the idea of a
page-break *in* a row or cell should be no surprise. If one wouldn't allow
this, and a construct like the above would span multiple pages, anything
other than shrink-to-fit would be impossible, since there is no possible
page-break that precisely coincides with the table-grid?
> > Just asking because, in the latter case, it may turn
> > out to be less unlikely/more dangerous than it seems
> > at first glance, albeit only a tiny bit.
>
> Well, less likely simply means that it can happen and sooner or later
> we'll have to deal with it.
Yep, sure thing. If we don't take care of it now, you can bet your life it
will turn up in a post on fop-user in less than a month after the eventual
release...
(Apologies in advance if the following are silly questions, since I'm not
yet fully 'at home' in the Knuth breaking code)
I'm wondering if the elements you're talking about discarding are Really
Wrong, or whether they are simply A Bit Off --so it would be
possible/feasible to introduce a 'correction factor' (most likely not a
primitive datatype, but a tiny nested compound) that increases/is adjusted
with each page-break occurring during layout of a given sequence? Recycling
or resetting instead of recreating? (By 'discard all elements starting on
the second page', I take it you don't mean to discard the elements on the
first page? Because they are Not Wrong, So Far? And when we reached the
fourth page, only the elements on page three would be discarded, or
everything after page one?)
Based on that: Would it be worth the overhead to perform a sort of
correction-pass over the first elements on a given Nth page before the first
step --or after the last step for the previous page?
Cheers,
Andreas
