[Xmlgraphics-fop Wiki] Update of "TableLayout/BlockProgressionDimensionOnTables" by JeremiasMaerki

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Xmlgraphics-fop Wiki" for change notification.

The following page has been changed by JeremiasMaerki:
http://wiki.apache.org/xmlgraphics-fop/TableLayout/BlockProgressionDimensionOnTables

The comment on the change is:
Notes on block-progression-dimension on tables

New page:
= 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 ==

 * [1] CSS2, table height algorithms: http://www.w3.org/TR/1998/REC-CSS2-19980512/tables.html#height-layout
 * [2] XSL-FO 1.0, fo:table, http://www.w3.org/TR/xsl/slice6.html#fo_table
 * [3] XSL-FO 1.0, fo:table-row, http://www.w3.org/TR/xsl/slice6.html#fo_table-row
 * [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.

== 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.

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-commits-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-commits-help@xmlgraphics.apache.org