Best Practice 4.18.10.2. 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 LaTeX 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 LaTeX 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.