Skip to main content

The PreTeXt Guide

Subsection 4.18.10 Table Philosophy

The Chicago Manual of Style [1, 13.1] says:
A table offers an excellent means of presenting a large number of individual similar facts so that they are easy to scan and compare. A simple table can give information that would require several paragraphs to present textually, and it can do so more clearly. … A table should be as simple as the material allows and understandable on its own; even a reader unfamiliar with the material presented should be able to make general sense of a table.
If you review the twenty tables presented in Chapter 13 of CMOS, that are of the type we implement, you will notice several things.
  • Only the first column is ever used for row headings.
  • Cells do not span multiple rows. (There is no analogue for @colspan.)
  • Column headings appear at the top, other than cut-in heads, which have a very particular form. (We have not implemented these, but would entertain a feature request.)
While our implementation allows for some presentational elements (borders, rules, alignment) our conversions will presume your table hews to the purposes described by CMOS. In particular, it is not a device for spatial layout of complex elements. You might find that the <sidebyside> and <sbsgroup> layout devices will suit that purpose better (see Section 4.22).

Best Practice Tables are Difficult.

Width is always at a premium, and then when a <tabular> has more than a few columns, the width becomes even more dear. When a <cell> has text that looks like a phrase or a sentence, rather than numerical data or symbols, it can be even harder to pack it all in. A common example is a schedule of talks at a small professional conference where each time slot (rows) might have two or three talks simultaneously in parallel sessions (columns).
We offer paragraph cells which automatically break lines, but you need to specify a @width on the <col> as a percentage to indicate where line-breaking happens. For manual line-breaking, a <cell> can be structured entirely by <line> elements.
The next complication is that the used for PDF output tends to make columns as wide as necessary and will not break lines without the devices mentioned in the previous paragraph. The HTML output can sometimes be a bit more forgiving and flexible. So we suggest building the output first and getting that right, and then the HTML is likely to follow along and not need much futher refinement.
In contrast to most of PreTeXt, you may need to experiment, refine your approach, iterate, and maybe do things contrary to usual best practices elsewhere. For example, the clickables for URLs and knowls might need to be short and less-informative in order to save some width. Abbreviations, initialisms, and acronyms can also save some width.