W3C home > Mailing lists > Public > xsl-editors@w3.org > April to June 2007

Clarification for tables: grid units, border-resolution and breaks

From: Vincent Hennebert <vincent.hennebert@anyware-tech.com>
Date: Wed, 04 Apr 2007 11:50:18 +0200
Message-ID: <461374DA.2040504@anyware-tech.com>
To: xsl-editors@w3.org
CC: fop-dev@xmlgraphics.apache.org

Dear XSL Editors,

Questions were recently raised on the fop-dev mailing lists about
tables, borders and breaks. We finally all came to the same conclusions
but I think it might be useful to add some statements to the XSL-FO
Recommendation, in order to ease the understanding for newcomers.


Grid units and area tree

It seems that the notion of grid unit is to be understood in terms of
area tree instead of fo tree. This is not obvious in the Recommendation
and it might help to explicitely write that. For example, when
a table-cell is broken over two pages, does it make one broken grid unit
or two separate ones? Thinking in term of FO tree, that would be one; in
term of area tree, that would be two. This is important for border
resolution, as we can see below.


Border-resolution in the collapsing-border model

For the (cells of the) first row of a table, border-before on the
fo:table and applicable fo:table-column objects play into border
resolution. When the table is broken accross several pages, do they also
play for the first row of each page? Or only the very first row of the
table? We agreed upon yes. This means that if
border-conditionality="retain" on fo:table, then it will appear on each
page (if it wins in the border resolution), which would be the same
behavior as in the separate-border model.

But if the fo:table-header is not omitted at page breaks, how should
border resolution be performed? Technically, the areas generated by the
table-cell children of fo:table-header are /replicated/ on each new
page, so they would have the is-first trait set to true. So assuming
that the conditionality of the fo:table's border-before is "discard",
should it play or not in the border resolution of table-headers on the
second and following pages?


Border-resolution and breaks

For simplicity let's assume we are inside a single table-body. The
question is the same if we are at the boundary between two table-bodies,
only the border-after/-before of the table-bodies will also play in the
resolution.
The border-after of a cell is to be determined from:
- the table-cell's border-after;
- the containing table-row's border-after;
- the following table-row's border-before;
- the border-before of the cell below.

If a break occurs /within/ a cell, should the following row and cell
still play in the border-resolution? We agreed upon not.

If a break occurs between two cells:
- should a full border appear at the bottom of the page (or column) and
  a full border at the top of the following page (column)? Or only half
  a border on each? We agreed upon the former.
- like above, should the two cells and table-rows play in the
  border-resolution of each border? Or only the previous cell and row
  for the border-after on the first page and the following cell and row
  for the border-before on the following page? We agreed upon the
  latter.

Those questions are easily answered if we consider that the table is
divided into independant grids on each page. Thus there would be a grid
line at the top and bottom of each page. Such a scheme would be logical
if grid units are entities which belong in the area tree.

If on the contrary the table must be thought as a single grid which then
is broken down on several pages (more on the FO tree side), then the
answers to these questions tend to be different.

That's why it may be useful to state that grid units pertain to the area
tree, and that border-resolution is performed on them at the area-tree
level.


Explicit breaks on table-header and -footer

I don't think it makes much sense to set the break-before and
break-after properties on fo:table-row and children of fo:table-cell
which are themselves children of fo:table-header and fo:table-footer
elements. It might be helpful to explicitely state that in the
descriptions of break-before and break-after.

I hope I was myself clear!

Thanks,
Vincent Hennebert
Received on Wednesday, 4 April 2007 17:05:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:58 GMT