On 23.03.2007 15:44:57 Vincent Hennebert wrote: > Guys, > > I've again stumbled upon uncertainties regarding the handling of > conditional borders in the collapsing-border model, and breaks inside > headers/footers. I'd like to have your opinions on these: > > > Table headers and footers: > Headers and footers are generated only once, and replicated on each > page. This means that cells in headers and footers only generate one > area, with the is-first and is-last traits set. Border- and > padding-conditionality don't apply here.
Conditionality still applies but because there's a header or footer serving as fence, the cell borders and paddings don't get discarded. Different wording, but essentially, yes. > Or perhaps that the border-before of the table should still be > considered? I mean, for the first header it would come into play, and > for following headers it also would only if conditionality=retain. > I think I'll go that way as it more closely matches the behavior of the > separate border-model. There's no table border in the collapsing border model when we're talking about areas. All levels of borders inside a table are merged. In the end, all you have are cell borders, nothing else. Only in separate border model do you have separate borders on the table and on the cells. > > Table body(-ies): > There are several uncertainties: > - should the border-before of the table and table-columns be considered > or not: do we consider that those borders only apply to the very first > (or last) row of the table? Or also to the first (last) row on each > page? The question remains whether there are headers/footers or not. > I would say yes. http://www.w3.org/TR/REC-CSS2/tables.html#table-layers answers that. 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") > - when we break /within/ a cell, should the following row come into play > for computing the border-after? As the row hasn't even been reached > yet, I'd say no. Right. That's the case in CollapsingBorderModelEyeCatching when currentCell is not null, and otherCell is null. > - 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. > - 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. > Tables and breaks: > - do breaks on headers and footers make sense? Obviously not, excepted > perhaps a break-before on the header's first row, or a break-after on > the footer's last row. But as the same effect can be achieved by > putting the breaks on the fo:table object, I think breaks on > headers/footers should be entirely discarded. Yes, breaks in headers and footers make no sense and should be ignored. > > Opinions? > Thanks, > Vincent Jeremias Maerki
