BTW, don't forget to use the Wiki as resource. Simon and I documented various cases (including the tricky ones) here:
http://wiki.apache.org/xmlgraphics-fop/TableLayout/KnuthElementsForTables/RowBorder http://wiki.apache.org/xmlgraphics-fop/TableLayout/KnuthElementsForTables/RowBorder2 http://people.apache.org/~jeremias/fop/KnuthBoxesForTablesWithBorders.pdf (The PDF has multiple examples, the last page shows the simplified approach which does not take interaction between body and headers into account when resolving borders) On 23.03.2007 16:54:37 Jeremias Maerki wrote: > > 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 Jeremias Maerki
