
Section13Table Calisthenics

A very minimal table, hence with left-justified cells, no borders. We do wrap the tabular element in a table element to get centering, numbering and a caption.

Tables can be used many ways. We describe long division of polynomials by using vertical and horizontal borders on individual entries of a table. The division lines are slightly thicker than the subtraction lines. This is a good example of the typical abuse of tables for horizontal and vertical layout. Also indicative of this abuse is that it might make more sense to call this a “Figure,” not a “Table”.

The next table describes how to construct tables via the tabular element. The table element may be used to enclose the raw table, so as to associate a caption and get vertical separation with horizontal centering.

The tabular element contains a sequence of row elements, and must contain at least one. Each row contains a sequence of cell elements and must have the same number in each row (acccounting for the use of the colspan attribute). The contents of the cell elements are the text to appear in entries of the table.

A sequence of col elements may optionally be used. But if one appears, then there must be the right number for the width of the table. They are empty elements always, and just carry information about their respective column.

Where the body of the table below has an entry, it means the attribute may be used on the element, and affects the range of the tabular described by the element. Employment of an attribute on elements to the right in the table will supersede use on elements to the left. Generally, every cell has right and bottom borders, but only cells at the left side of the table have a left border and only cells across the top have a top border. Only one cell has four borders.

Bully Pulpit: Vertical Rules in Tables

One of the goals of PreTeXt is to gently guide authors towards good choices in the design of their documents, even if we do not claim to know it all ourselves. Take a close look at that table about tables. What's missing? No vertical rules. Try living without them, you will not really miss them. If you think you need to divide a table into two halves, maybe you really need two tables (and then see the “side-by-side” capabilities, Section 23).

In the documentation for his excellent package, booktabs, Simon Fear gives two rules for what he calls “formal tables”: (1) Never, ever use vertical rules, and (2) Never use double rules. We have resisted the temptation to enforce the former and have provided an alternative to the second (three thicknesses). He refers to using tables for layout as creating “tableau.” If you are finicky about the look of your work, the first three pages of the documentation is recommended reading.

That all said, we now give several examples in order to stress and demonstrate our code.

An example of aligning table cells' contents horizontally. See the source for comments.

Example from above, but now with horizontal rules, plus an extra row to test the bottom border. See the source for comments.

For a table without a caption, create a <tabular> and place it inside a <sidebyside>. This will allow control over the horizontal placment, but without a caption, there is no number, and the tabular cannot be cross-referenced.

 One

Same example as before, but now with vertical rules. See the source for comments.

This example tests several things. In output, figures, tables, listings and side-by-sides are “floats” whose placement can migrate, but we have tries to supress this behavior. However, a float that is the first item of an “environment” (like a theorem or an example) can still float to a position before its title. If that does not happen here, then our additional defenses are working.

This example also checks that the total number of columns is correctly computed from the first row, which features several colspan attributes.

A bare minimum table (one row with one cell) to test edge cases:

Table cells with a fixed width where text wraps are known as “paragraph cells”. A cell will be created as a paragraph cell if and only if it has <p> children. And such cells should only have <p> children. The width of a paragraph cell is determined by a width attribute on the corresponding <col> (as a percentage). If no width is specified (or there isn't even a <col> in the first place) then xsltproc will abort. If the column has a non-paragraph cell with contents that are wider than the paragraph cells, results will be undesirable. There is presently no implementation for a paragraph cell that has a colspan greater than $1\text{,}$ although cells with colspan greater than $1$ that are above or below a paragraph cell will behave. Setting width on a <col> that has no paragraph cells may produce unexpected results. A valign for the parent <row> (or the ambient <tabular>) can control vertical alignment (top, middle, or bottom). A paragraph cell's halign attribute (left, center, right, or justify) controls how the text is justfied. Cells inherit halign from <row>, <col>, and <tabular> in that order of preference. In a non-paragraph cell where halign='justify', the horizontal alignment will match the behavior of halign='left'.

Table cells can have multiline content using <line> elements. This is not the same thing as a paragraph cell—line breaking will happen precisely where the author tells it to. A <line> will not break, even on a narrow screen. If a cell uses a <line>, it must only use a sequence of <line>s and no other content. As with paragraph cells, you can use a valign attribute for the row.

This is a table torture test with many combinations of halign, valign, colspan, <p> children, and <line> children.

And now a <sidebyside> with a <table> and a <tabular> to check that width is scaled appropriately. See Section 23 to learn about <sidebyside>s.

Tables are formed in output with copious use of the \multicolumn macro to override more global alignment settings, and to spread the content of one cell across several columns. However, sometimes 's special characters have behaved badly in this situation. So the table below, two items per row, is just designed for testing. But of course, it should still render fine in other formats. The five test cases are from 8.3, but without 50 alphabetic characters and 8 digits, which should not be problems in this context. The first column's entries are forced to be wrapped in a \multicolumn by specifying their horizontal alignment. The second column's entries should not be wrapped in a \multicolumn.