but gets the job done for most simple and medium cases. If you really
need a complex table, you will need to use tex or dbx tag to
insert directly your formatter dependent code.
PlainDoc tables are formatted by having column headers underlined with equals signs and then supplying the table data in the columns. Use space characters for alignment and formatting.
<<table: example caption Header1 Header2 Header3 ========= ======== ========= row1col1 row1col2 row1col3 row2col1 row2col2 row2col3 last col overflowing row3col1 row3col2 row3col3 row4col1 n.b. empty line starts "row mode" table where each line row4col2 represents a cell and the amount of text in each cell row4col3 can exceed the width of the column (wraps to multiple lines) row5col1 row5col2 row5col3 : row6col1 row6col2 row6col3 >>
This renders as (may appear on separate page due to underlying formatter's float placement algorithm): see table 3.
Table 3:example caption
| Header1 | Header2 | Header3 |
|---|---|---|
| row1col1 | row1col2 | row1col3 |
| row2col1 | row2col2 | row2col3 last col overflowing |
| row3col1 | row3col2 | row3col3 |
| row4col1 n.b. empty line starts "row mode" table where each line | row4col2 represents a cell and the amount of text in each cell | row4col3 can exceed the width of the column (wraps to multiple lines) |
| row5col1 | row5col2 | row5col3 |
| row6col1 | row6col2 | row6col3 |
Also longtable keyword can be used. That will cause the table to be split across several pages (if it's long enough).
minitable keyword causes the table, which should not be big, to be placed inset in the text, i.e. the text will wrap around the table.
Table 4:Minitable caption
| Col1 | Col2 |
|---|---|
| Abc | This is minitable row 1 |
| Def | This is 2nd row |
Column widths are controlled by the number of equals signs under the
table header. They are NOT computed automatically. You can tweak the
table by adding or deleting equals signs. The amount of space per
equals sign is controlled by
~texcolwidfactor~ and
$dbxcolwidfactor in pd2tex source code. Rather than tweaking
these factors, you are encouraged to experiment and iterate the number
of equals signs in your document until you are happy. Eventually you
will gain insight as to what is a good number of equals signs.
When composing a table, you usually horizontally align the columns. This means that the text MUST fit under the column header. However, sometimes it would be better if the text wrapped to multiple lines instead of forcing the column very wide. For the last column of the table this is accomplished simply by letting the text run off the right edge. However, for the other columns, you need a different trick:
If an empty line is encountered in a table definition, the next row is described by having one column per line. The number of lines you supply must match exactly the number of columns in the table. Otherwise pd2tex will get confused and misformat your table - and quite often most of the rest of the document.
The table facility is not fully flexible,
but gets the job done for most simple and medium cases. If you really
need a complex table, you will need to use tex or dbx tag to
insert directly your formatter dependent code.
If the line immediately following the equals signs, has keyword WIDTHS: followed by comma separated list of numbers, then these numbers are used for table column widths. An empty specification leaves the column width as specified by the equals signs. A plain number specifies the width as absolute millimeters. A number prefixed by plus or minus sign makes the column that much wider or narrower, respectively.
If line immediately following the equals signs has keyword OPTIONS: then the rest of the line is parsed for table options. The first option specifies the reference tag for the table (e.g. for use in a see specification).