Notes on block-progression-dimension on tables

The spec defines the block-progression-dimension property to be applicable to fo:table, fo:table-row and fo:table-cell.

This page shall document how we are going to treat the block-progression-dimension on tables.

Links into the specification

• Wiki Markup
  \[1\] CSS2, table height algorithms: http://www.w3.org/TR/1998/REC-CSS2-19980512/tables.html#height-layout

• Wiki Markup
  \[2\] XSL-FO 1.0, fo:table, http://www.w3.org/TR/xsl/slice6.html#fo_table

• Wiki Markup
  \[3\] XSL-FO 1.0, fo:table-row, http://www.w3.org/TR/xsl/slice6.html#fo_table-row

• Wiki Markup
  \[4\] XSL-FO 1.0, fo:table-cell, http://www.w3.org/TR/xsl/slice6.html#fo_table-cell \\

Height of a row

The height of a row is determined according to the rules in \[1\]. Elements in this calculation:

• implicit height of each cell's content
• block-progression-dimension on each cell
• block-progression-dimension on row
• resolved borders (bpd only specifies content height)
  

block-progression-dimension on fo:table

See \[1\] for usage. This is all pretty vague and it seems that this property is ignored my most implementations.

Handling break conditions in tables with respect to block-progression-dimension

The problem is slightly different to block-container, for example, because there is no overflow property. It seems that the cell/row heights are always enlarged to fit all the content, thus relaxing ".maximum" constraints on block-progression-dimension properties. It's important to note that it's easy to create conflicting values for b-p-d.

Still, block-progression-dimension is defined to specify the "block-progression-dimension of the content-rectangle for each area generated by this formatting object". This statement needs to be relaxed in the context of table layout especially for fo:table which returns all kinds of areas. You end up looking at the block-progression-trait for the areas created for fo:cell.

While fo:block-container "generates one or more viewport/reference pairs", fo:table-cell "generates one or more normal reference-areas". This is probably of no significance. Our interpretation for block-containers is so, that we have to put the content into a stretchable box whose height is defined by the block-progression-dimension. If the content doesn't fit, another stretchable box with the same features is generated on the next page, the next part of the content fit into the box.

Now the questions is how to apply all this to table-cells. One could argue that block-progression-dimension simply establishes minimal cell/row heights if they are specified. The other question is whether an explicit height generates an implicit keep-together for the content that fits this minimal height. Further, it's not clear (to me) if in a break condition the second part also has to have the same minimal height as the first part, or if the rest is simply rendered as if there's no explicit height.

Calculation row heights in FOP

CSS2 doesn't specify how the individual row heights are calculated. In FOP only the last grid unit (in block-progression direction) of a cell is used for height calculation. For row-spanned cells the row heights of the previous rows occupied by this cell are subtracted from its own intrinsic size to calculate the row size. See TableContentLayoutManager.createElementsForRowGroup().

Curiosities

row-height trait

In \[3\] there this: "The method for determining the height of the row in the grid is governed by the row-height trait." 

In \[4\]: "The method for determining the block-progression-dimension of the cell in the grid is governed by the row-height trait."

The row-height trait is defined nowhere in XSL-FO or CSS2, although it should be quite clear what it means. But still, I fail to see the significance of this statement.