On Mar 23, 2007, at 18:21, Vincent Hennebert wrote:
[Jeremias: ]
<snip />
http://www.w3.org/TR/REC-CSS2/tables.html#table-layers answers that.
<snip />
The
image should help you understand. An example: take the before
border of
the first cell of a table header. The elements that influence the
resolved borders are: table, column-groups if applicable, the column,
table-header, the first row in the table-header and the cell
itself. All
the borders of these elements have to be combined. That's what's
already
(!) implemented in CollapsingBorderModelEyeCatching (for
border-collapse="collapse")
That doesn't tell anything regarding page breaks!?
Hèhè, that always tends to happen with references to CSS. :-)
If the table is broken across several pages and the header shall be
replicated, do
border-before for table and table-column play again in border-
resolution
for the second and following headers?
YES! Not only border-before even, I think, but that is open for
interpretation. The column's border-before *and* after need to be
considered for each body, header/footer that appears on a given page.
One could also argue that the column's span the entire table for each
page, so the column's border-after does not need to be considered for
the header's last row, for instance.
Apart from that, there is the tiny note, of course, that we're
talking about hypothetical situations, in which border-conditionality
is overridden for all table-elements.
The default value being "discard" makes the interplay between border-
collapse and border-conditionality actually much simpler than it
seems at first...
<snip />
- when we break at a grid line, should the two rows meeting a the
line
count in border resolution? Or only the row before for the
border-after at the end of the page, and the row after for the
border-before at the beginning of the following page?
I would go with that latter.
That's right.
Fine (that means that the border may potentially be different at the
bottom of the previous page and at the top of the next page).
Only if you have no header/footer. If there is a repeated header/
footer, then the border will neatly be the same for all pages. If you
have no header or footer, then overriding border-*-
width.conditionality on the table or table-body is enough to prevent
weird effects.
Do we
agree that those two latter cases are not described by the spec?
As far as I remember, yes, since XSL-FO refers almost entirely to CSS
(which, because of its correlation with HTML, has no concept of page-
breaks). This still leaves some room for the implementors FTM...
- when we break at a grid line, should the entire border appear
on each
page, or the higher half at the bottom of the first page, and the
lower half at the top of the following page?
I would also go with that latter.
No, the entire border has to be painted. This is
BorderProps.COLLAPSE_OUTER/COLLAPSE_INNER as used by the
renderers. See
the BorderProps class.
So the grid line at the page break would have two borders, one at the
bottom of the page, one at the top of the next page?
That's fine for me, but again I think it's specified nowhere.
Hmm... not exactly. Think of the part of the table on one page as an
independent subgrid, that has nothing to do anymore with the
preceding or following subgrid. It is the gridline which is split in
two, and each of the new gridlines will have one fully resolved
border. In a sense the border is duplicated, yes... :/
Cheers,
Andreas
