6.1 Tabular structure

6.1.1 Aligned tuples of block-level constructs

Standalone blocks cannot be adjacent to each other in the inline-progression direction.

• A block-level construct typically continues the block-progression direction.

Tuples of adjacent blocks are useful for associating pieces of information, including

• sets of one-dimensional information;

  • each row of the table is a set of information items;

  • as many rows exist as there are sets of information,

• two-dimensional information;

  • the columns represent one axis of the information;

  • the rows represent another axis of the information;

  • the cells represent the relationship between the members of each axis.

The name of the construct shouldn't prejudice how the construct is used.

• Don't think that only tables in your XML information can use this construct for layout.

• Regard the construct as a layout facility for multiple block-level constructs in the inline-progression direction of the parent block.

• For two-column tables, a list construct may suffice or offer other layout features you need.

The content of the blocks may determine the edges of the blocks.

• An auto-layout table adapts column widths to the widths of the cell contents.

  • The start and end edges of each block in a set are relative to the edges of respective members of all sets.

• The fixed-width table layout ignores the widths of the cell contents.

• Once determined, the widths of the columns are fixed for the entire table.

6.1.2 Table- related formatting objects

A table is a block-level construct.

• There are two ways to begin a table-related hierarchy.

  • table-and-caption :

    • lets you specify a caption that is copied to every page in which a portion of the table is presented,

  • table :

    • is the collection of header, footer, and body contents of the table.

• Table widths are specified as with other block-level constructs, by providing

  • possible fixed width,

  • possible width relative to containing block,

  • possible sum of all column widths.

• There are no limitations on the location of table or table-and-caption objects in an instance.

  • Tables can be nested within table cells.

  • Tables can be positioned inline through the use of the inline-container object.

• Tables have the same kinds of attributes as other block-level constructs.

The indeterminate room for rows on a page necessitates special handling of page breaks.

• The transformation creating the XSL-FO instance cannot know how much of the table will fit on each page.

  • The formatter is in charge of determining where the page breaks belong.

• Body content dictates how many pages are used by the rows.

  • table-body (mandatory and possibly repeated):

    • contains the rows of the table that are not repeated and make up the body of the table content.

Constructs of a global nature are rendered on each page that gets table content.

• table-caption (optional):

  • is positioned according to the caption-side property,

  • is optional so that the table-and-caption properties can be used to align the nested table .

• table-header (optional):

  • is rendered before the before edge of the rows of the table body used on each page with table body content,

  • may be unnecessary; if the header need not be repeated, define all rows of the header once in the body before the first row of the body content.

• table-footer (optional):

  • is rendered after the after edge of the rows of the table body used on each page with table body content,

  • may be unnecessary; if the footer need not be repeated, define all rows of the footer once in the body after the last row of the body content.

One strategy for building rows in a header, footer, or body row group is to make everything containerized; the other strategy is to have these groups triggered by cell properties.

• The containerized strategy implies the use of table-row objects;

  • each one contains table-cell objects;

  • it supports transformation of row-related container constructs in source information;

  • this is an opportunity for row-wide inheritance of properties.

• The triggered strategy implies the use of only table-cell objects;

  • you'll have to use starts-row and ends-row properties;

  • this supports algorithmic breaking of cells into rows when source is not containerized;

  • properties represent conditions to be met and not actions to be performed;

    • a cell with starts-row following a cell with ends-row does not produce an empty row.

• Multiple table-body objects are allowed in a single table;

  • each table-body object allows a portion of the table to use a different row strategy;

  • each row group may be defined differently than other row groups, but a single row group can only be either containerized or triggered.

Column widths may be calculated from content.

• This requires that the table has the table-layout property of " auto ".

• This is the initial value for the property and must be changed to get fixed layout behavior.

• Implementation-defined algorithms will not ensure the same presentation between different processors.

Table column properties are specified using table-column .

• This is an empty formatting object that does not generate any areas.

• The column number need not be specified if it is equal to the previous sibling specification's column number plus one.

  • The first column specification is assumed to be for column one, if the column number is not specified.

• Formatting properties in this object can be utilized by cells by explicitly using the from-table-column() function.

Column widths specified by column-width can be relative or explicit.

• It may need to be specified either way for all columns.

  • This is the case when inline-progression-dimension is an explicit length and the table-layout property is " fixed ".

• A relative value can be given with a "unit" specification.

  • Each relatively sized column width is specified as a quantity of abstract units.

  • The sum of units in all unit-specified columns is the basis of a single unit's value.

  • The function proportional-column-width( number-of-units ) :

    • returns the length value equal to the length of the number of units requested .

  • The table-layout must be " fixed " and the inline-progression-dimension cannot be " auto " (but may be " 100% " to be as wide as possible).

• A fixed value can be given with a length specification.

• You can mix columns with relative and fixed specifications;

  • the relative values are calculated from the remainder of the table width after subtracting all of the fixed values.

A summary of table structures and row grouping strategies is shown in Figure 6-4.

• Thick lines indicate only those objects that can be the apex of a table structure.

• The choice of row strategy is within each sibling row group (header, footer, or body).

  • A choice for a given row group does not dictate any specific choice for the sibling row groups.

Figure 6-4. Possible table formatting object hierarchies