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

Reply via email to