Chapter 6. Tables
| A tabular presentation can help the reader by arranging information in a rigid partitioning of groups. These groups can be simple tuples of aligned block-level layout areas, where collections (rows) of collections (columns) of information are presented. In this case, the columns and rows are not being used as indices of a Cartesian plane. The grid is only a layout strategy. For example, when laying out columns of aligned formatted paragraphs in multiple languages, each piece of information is a standalone paragraph of a different length, thus requiring that the first lines of all translations of each paragraph be aligned. An example of a side-by-side bilingual text presentation of an excerpt from the Canadian statute "Employment Equity Act, S.C. 1995, c. 44" is shown in Figure 6-1. Note how the numbered paragraphs are aligned at their before edges even though the lengths of the paragraphs are different. Figure 6-1. English and French side-by-side tabular presentation Alternatively, the groups can be block-level layout areas in a two-dimensional relationship between members of collections. In this case, the information is in a traditional Cartesian arrangement at the intersection of indexed row and column axes. An example of a Cartesian grid presentation of hockey standings is shown in Figure 6-2. Note how rows are spanned for the "City" and "Points" headings, and columns are spanned for the "Games" heading. Figure 6-2. Cartesian grid tabular presentation This layout facility supports numerous block-level areas arranged in the inline-progression direction, where the table contains rows (in block-progression direction) of cells (in inline-progression direction) where each cell contains block-level areas (in block-progression direction). Without such a construct, block-level areas would be arranged only in the block-progression direction. Column widths are fixed for the length of the table. Width values can be specified in the supplied objects and properties, or they can be based on an automatic weighing of the contents of all cells of the table, as when an HTML browser balances column widths based on content. The two layout objectives using the same layout constructs are illustrated in Figure 6-3. The page on the left shows a collection of tuples of information, where each tuple is in a row and each member of each tuple is in a column. The page on the right shows a coordinate-based layout of cells of information, where the ordinate is along the columns and the abscissa is along the rows. In neither case are the heights of the individual cells constrained to be either different or the same; the layout supports any cell to be any height and will align the before edge of all cells of a given row along a common position. Figure 6-3. Differing uses of the tabular layout construct Note that the column widths can differ from each other and are fixed to the same values for all rows in the entire table. As in HTML, the widths may be based on balancing of the content of the columns in all of the rows (which is the default in XSL-FO tables). The source information needn't be modeled by a table construct, though historical use of structured information tools often forced information designers to model explicit table constructs in their structures. Such models may fail to fully capture the semantics of the information, resulting in a loss of richness and utility in the information source. Information from any model can be presented in a tabular fashion. XSLT or any other transformation technology can be used to rearrange the source information into the tabular relationships by expressing the information found in the source XML vocabulary into the table constructs of the XSL-FO XML vocabulary. It is important to remember that the table is a layout construct in XSL-FO, not an information construct. A table is a block-level construct that itself continues the flow in the block-progression direction. Tables in XSL-FO have a compound structure with many well-defined behaviors. The caption, header rows, and footer rows are constructs repeated on all pages where the table's body rows are rendered. Column properties can be specified once for all cells that are in a given column. This is because the linear serialization of a two-dimensional construct necessarily favors one dimension over the other cells are contained within rows, not columns, so a column-oriented construct is necessary to address the second dimension of property assignment. Column-spanning and row-spanning features provide flexible table cell definition for special needs. Included in this chapter. This chapter includes discussion of the following XSL-FO objects:
|
