LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

 Options: Use Forum View Use Monospaced Font Show Text Part by Default Condense Mail Headers Message: [<< First] [< Prev] [Next >] [Last >>] Topic: [<< First] [< Prev] [Next >] [Last >>] Author: [<< First] [< Prev] [Next >] [Last >>]

I would like to bring another topic up for discussion, namely the fact
that there are currently virtually no high level, generic mark-up
commands for the design of tables.

Being a Mathematician, I never worried too much about the typesetting
of tables, because tables rarely are rarely used in my field, and if
so, they are rather trivial.  In the last few weeks I was helping a
Linguist typesetting some paper, and although LaTeX performed
miraculously well in handling the mixed use of three different
alphabet (Latin, Greek, and Phonetic), the typesetting of two slightly
non-trivial tables proved to be a major pain and a main source of
delay for the whole project.

First I should say that there seem to be some unwritten conventions in
the field that seem not unrelated to the fact that most people use
commercial word processors and thus these conventions reflect maybe
more about the current capabilities of MS Word than anything else.  On
the other hand they are too important to be ignored if LaTeX wants to
claim some sort of universality.  To be more concrete, people seem to
want different line styles for the separator between entries in the
table (dashed, gray, dotted, double etc.) to indicate certain
relationships between the entries.

After some hacking, and the use of xfig for one of the tables, I more
or less managed to produce the required output with LaTeX, but the
solution was neither efficient nor in line with the LaTeX philosophy
of providing generic mark up constructs.

Thinking more about the matter, it seems that the whole table
mechanism in LaTeX (the tabular environment and the various
patches/replacements to it which exist in the tools distribution and
on CTAN) are essentially on the level of plain TeX and visual mark-up.
Even a very reasonable request like "I want my table to stretch to the
whole width of the page rather than stop 3mm before the right margin"
requires fiddling with @ expressions in the tabular*
environment---which is not elegant, to say the least.

So I would like to make a few suggestions.  I haven't done any deep
similar ideas or problems.

1. One should identify logical units of tables (like \section etc.) in
the body of a LaTeX document.  A (partial) list of these could be

- column/row headers (which would probably be typeset in a different
style or alignment option than the rest of the column/row.

- 1st level, 2nd level, 3rd level etc. column separators, the same for
row separators, separately specifiable for every entry in the table.

- Different "data" types of entry (decimal number, integer, paragraph,
unbreakable line etc.)

2. The possibility to define more of the above entry types.  I am
thinking in particular of the possibility to say that certain entries
are of type A, and the table mechanism would automatically balance all
entries of type A to have the same width.

3. The introduction of a \tableclass command in analogy to
\documentclass.  The documentclass would select a default table class,
but the user could issue a new \tableclass commands before each table
if necessary for the particular material.  The table class and its
options would define the visual appearance of the generic mark-up
features.  For example, it may map a 1st level column separator to a
double line, a 2nd level column separator to a single line etc.

4. I believe that many or all instances in which one currently needs
to issue a \multicolumn command could be better handled by allowing
a multilevel table structure, i.e. each entry could be a table by
itself, and the algorithm would sensibly deal with placing it
seamlessly into the higher level table.  Very similar to nested lists
in current LaTeX.

This will require something more sophisticated than merely placing the
inner table into a box and then building the outer table around the
box, because this would make alignment between rows or columns between
different inner tables impossible.  Rather, the algorithm should be
able to resolve the whole table in units of its finest subgrid, and
then build the table as one entity.

Maybe it would be still useful to have something like \multicolumn,
but with a more systematic syntax, e.g. as a "level -1" column
separator which breaks into the adjacent column, a "level -2" column
separator which "eats" two column separators, and so on.

Does this sound like a reasonable approach?  Does it seem possible to
program such things in TeX with finite effort? (I have to admit that I
don't know to much about the deep mysteries of plain TeX.)

Marcel