Comment on row height calculation in FOP
converted to 1.6 markup
|No differences found!|
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
 CSS2, table height algorithms: http://www.w3.org/TR/1998/REC-CSS2-19980512/tables.html#height-layout
 XSL-FO 1.0, fo:table, http://www.w3.org/TR/xsl/slice6.html#fo_table
 XSL-FO 1.0, fo:table-row, http://www.w3.org/TR/xsl/slice6.html#fo_table-row
 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 . 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  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().
In  there this: "The method for determining the height of the row in the grid is governed by the row-height trait."
In : "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.