Hi, Thanks for your inputs, Andreas and Jeremias.
The whole thing suddenly makes sense when you think in terms of area tree instead of fo tree... Still, I think it's not obvious by reading the spec and I'll probably ask for clarification on [EMAIL PROTECTED] And there is a remaining question raised by Andreas: <snip/> [me:] >> 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? [Andreas:] > 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. Interesting point of vue. I think it can be summarized by the attached picture. Jeremias' position corresponds to 1., and I suspect this is the more common understanding. Andreas' is 2., but I'm afraid you'll be alone ;-) Mine's tends to be 3., although I'm ok with 1. If there is no other comment I'll go with 1. > 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. Still, nothing prevents users from trying to achieve those weird effects ;-) <snip/> >>>> - 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... :/ I'm ok with that now :-) Thanks, Vincent
