List Info

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




Clarification for tables: grid units, border-resolution and breaks
country flaguser name
France
2007-04-04 04:50:18
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



[1]

about | contact  Other archives ( Real Estate discussion Medical topics )