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


Definitive XSL-FO
Definitive XSL-FO
ISBN: 0131403745
EAN: 2147483647
Year: 2002
Pages: 99
Authors: G. Ken Holman

Similar book on Amazon

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net