Tables have a two-dimensional structure because of the organization of the table into rows and columns. These row and column structures intersect to identify the characteristics of the table entry at the intersection. The layout of a table must simultaneously align table entries horizontally in a row and vertically in a column. The table width is determined by accumulating the widths of each column. In turn, column widths are determined by the widths of the entries in the column. Similarly, the table and row depth are determined by the depths of the entries in each row. The arrangement of table entries can be expressed separately from the actual widths of rows and columns. This separation of the topology (ordering) of entries from the geometry (positioning) of entries will be exploited in Chapter 5.

The two-dimensional nature of tables differentiates table formatting from simpler text formatting. Tables deal with areas and graphical relationships, both of which have two degrees of freedom. Lines and paragraphs of text have only one degree of freedom (where to break the line), although even then a complex algorithm may be necessary to produce aesthetic line breaks [Knuth, Line Breaking].

The conventional two-dimensional structure of tables is illustrated in Figure 4-1. The rows and columns intersect to form the table entries in the panel which is the main body of the table. The area with row identifications at the left of the panel is called the stub. The column headings in the area along the top of the panel are called the box head because when a table is fully outlined the column heads are completely boxed. Some headings group several columns together and are referred to as spanning heads or spanning subheads, depending on the depth at which they occur in the box head. Spanning row headings for several rows are also possible.

As an example, the box head in the table of Figure 4-1 has completely determined the width of each column because the headings themselves are wider than the information in the columns. In other tables, the table entries may be wider than the headings above them, and they would then determine the column widths.

Various graphic embellishments to the basic row and column structures help convey the table information. Dividing lines called rules help separate dissimilar parts of the table. The box head and stub in Figure 4-1 are completely outlined; all possible horizontal and vertical rules are present in the headings. Some table designers prefer only horizontal rules (see below for more discussion of table rules).

The word `rules' will appear frequently in this and the next chapter, in relation to the typographic lines (rulings) drawn in a table to separate rows or columns. This use of the word is traditional in the graphic arts. However, it may be confused with the notion of `style rules' from the previous chapter. Throughout this thesis, the word `rule' by itself refers to a typographic line and terms `style rule' and `formatting rule' refer to a way of doing things.

The content of table entries may vary considerably. Certainly textual and numeric information are commonly organized into tables. Other types of information often included in tables are pictures, illustrations, mathematical equations, and even other tables.

In most table designs, the table entries are fully contained within the row and column intersection. More general table designs permit the content of one table entry to flow into another. Connected entries would be necessary when folding a long table entry of text into two column entries, or when flowing a caption around several illustration entries. This capability is necessary to extend table formatting to full page layout requirements.

This section discusses the wide range of typographic details required to format tables. Careful text placement is an obvious requirement steming directly from the two-dimensional structure of tables. Alignment choices to guide the placement are also needed. Formatting attributes can be applied to different parts of the table structure. The treatment of whitespace, typographic rules, and rows of dots between table entries are devices for guiding the eye along rows or columns. Footnotes on table entries must be referenced and positioned appropriately. Finally, readability concerns in table formatting are important.

Tables tend to be awkward to handle in page composition. They must be treated separately from the running text because they contain separate information. However, the tables may be too wide for the page width or too long for the remaining space on the page, or even too long for the page height. Following are some of the problems and solutions for dealing with large tables.

The use of a fixed width character model for table formatting is a key simplification available with typewriters or line printers. The fixed width of each character on these devices permits a coarse grid with complete specification of the character positions. Spreadsheet programs take advantage of this to provide regularly spaced grids and simple typographic features. There are fewer possibilities for positioning and aligning characters when using a fixed grid, making the formatting problem much simpler. The typewriter tab stop model is often provided in document composition systems as a rudimentary table formatting capability.

Tab stops are based on a physical escapement mechanism in mechanical typewriters. The carriage in old typewriters is spring-loaded and advanced to the next character position whenever a key is pressed. The tabulator key permits the carriage to fly to the right past several character positions until stopped by a mechanical `finger.' These fingers are the tab stops. Any number of them can be requested along the carriage. The measurement between stops is always in units of character positions. Furthermore, the stops indicate only the left margin of a tab column. Aligning numeric information or centering headings requires spacing the carriage manually. Teletype devices also have tab stops, but they standardized on 8 characters between stops to ensure that the sending and receiving devices would place characters in the same positions. Early computer terminals also have 8-character tabs, while later ones have settable tab stop positions.

Document formatters extended the typewriter tab stop model to align numeric and centered information. Defining a tab stop requires specifying a formatting attribute for the position of the stop and for the alignment choice. Different formatters choose to interpret the tab stop differently as determining a position (Runoff) or a column (Scribe). The entries in Figure 4-5 are aligned at tab stops according to the different interpretations made by the Runoff class of formatters and by Scribe.

Defining a column to be the space between two tab stops creates an inconsistent notion of a column. Two short pieces of text can be positioned in the same column if the first is left-aligned and the second right-aligned; two longer pieces of text will be positioned in different columns. The tab stop defining a column does not imply a boundary, only an alignment point. A long line of text is not folded when the text extends beyond the next tab stop. Thus editing the text entry may result in aligning it in a different column than before.

Tab stops provide only a very limited table formatting functionality with few typographic features. They are not satisfactory for most tables, yet they are the only table formatting capabilities offered by several document composition systems. The tab stop model breaks down completely when table entries must be folded from one line to the next. The next section discusses the first real table formatter available with an electronic document composition system.

The tbl table formatter [Lesk, tbl] for troff is a preprocessor that accepts a table definition and generates formatter commands to render the table. The table definition is in two parts: the table arrangement part and the table content part. These parts may be intermingled to keep the arrangement definition close to the affected content. The last row definition is reused whenever more row contents are encountered than defined in the arrangement part.

The table arrangements may include spanned headings across arbitrary columns or rows. However, the specification of spanned column headings is asymmetric to spanned row headings. The spanned column heading is specified in the table arrangement part while the spanned row heading is specified in the table content part or the heading, as discussed in Chapter 2.

Folded table entries are possible with the column width stated explicitly. Whole paragraphs or complex formatted objects may be included as a table entry. Should the table contain objects formatted by another troff preprocessor, the order of processing must be carefully chosen to avoid interaction between the preprocessors.

Formatting attributes may be specified to apply to all entries in a given column. No similar capability is provided for rows, although troff commands may be inserted before and after rows to control some of the formatting attributes.

Rules may be specified within the table in a stylized fashion. Thin single and double rules may be specified; tbl computes the intersections between single and double rules that are only a single thickness and color. There is a shorthand specification to box all table entries. Rules are specified in an asymmetric fashion where vertical rules are included with the table topology and horizontal rules are included with the table content.

The position of table entries is computed by troff. tbl assigns the width and height of table entries to troff registers and uses troff commands to compute the position of table entries. Thus, tables are limited in complexity by the number of available registers, which is in turn limited by the two-character naming restriction.

Long tables with repeated rows can be formatted with tbl. Distinct continuation headings can be supplied explicitly or the original box head can be repeated for each table fragment on successive pages.

The tbl preprocessor has the generality to accommodate most table arrangements. The specification of spanned row and column headings permits general layouts. The asymmetric treatment of rows and columns often impacts the ease of table specification. The content of tables is limited by troff resource restrictions and by the interaction with other troff preprocessors such as eqn and pic. Recursive content is not possible. For example, a troff document cannot contain both a table of mathematical equations (tbl includes eqn) and a display equation that includes a table of equation fragments (eqn includes tbl), since the troff preprocessors must be executed in a sequential pipeline order.

There is no table formatting preprocessor for TEX. Equivalent functionality is provided through extensive macros [Knuth, The TEXbook, Chapter 22]. The TEX halign (horizontal alignment) primitive defines a template for the table layout that specifies a separate formatting environment for each column. Successive rows of the table then match entries in the preamble. Complications arise when introducing horizontal and vertical rules. Sophisticated knowledge of TEX is required to master them [Knuth, The TEXbook, Chapter 22].

The LaTEX macro package [Lamport, LaTEX] provides a specification language similar to tbl for defining tables. The table topology is defined as successive rows of column entries with vertical rule codes. The LaTEX scheme provides a more robust implementation than tbl since it is based on the TEX box and glue abstraction, whereas tbl simulates this abstraction with troff macros. The difference is revealed in the success with integrating mathematical notation in tables. LaTEX provides a more reliable and predictable table formatter compared to tbl and eqn which may fail in unexpected ways when interactions between the two preprocessors occur.

However, the LaTEX table formatting macros do not ensure that aesthetic layout is easily accomplished. The LaTEX manual cautions authors of complex tables that some final hand tuning of the space around boxes will be required to achieve the best results [Lamport, LaTEX, p 105].

None of these previous approaches provide interactive table design capabilities. They are all batch-oriented formatters. The TABLE editor [Biggerstaff, TABLE] is a prototype interactive graphics editor developed for editing complex structures. The prototype editor provides an interactive front end to the tbl formatter as part of an experiment in object-oriented programming. The objects implemented were tables and text. Operations on objects would be determined by the nature of the objects, such as deleting a row or column from the table. Editors were to provide WYSIWYG feedback so that the screen image would be identical to the printed form. Several software engineering concerns about object-oriented programming were tested in this experiment, such as the ease of building and modifying an editor, and the responsiveness of editing interactions. The results favor the first two criteria but raised some concerns about the latter.

The TABLE prototype is a WYSIWYG editor for table structures. The table layout is presented graphically. The layout of table objects is accomplished with the tbl preprocessor. This provides TABLE with sufficient layout generality but with the associated performance penalty of using batch programs. The paper recommends developing a custom post-processor for a production system [Biggerstaff, TABLE, p 343].

The user interacts with TABLE objects through a selection mechanism. The granularity of table selections are the entire table, a table element, or selections within the object contained in the table element. Positioning commands allow the user to traverse the table structure along rows or columns and from the table to within the table element objects.

The TABLE prototype succeeded in providing a graphical interface to complex table structures. Table designs could be generated more quickly and more accurately with TABLE than by coding tbl commands directly. However, TABLE inherited from tbl the resource restrictions, the lack of object structure characteristic of troff preprocessors, and the sluggish performance of a large batch formatter. TABLE lacks operations suited to the logical structure of tables through limitations in its internal table data structure and its selection mechanism. There is no style provision in TABLE, possibly because tbl did not provide one to be inherited.