Many documents, both historical and contemporary, include not only text but also graphics, artwork, and other images. Although such images could be represented directly within SGML, SGML is not primarily designed for that purpose, and it is standard practice to include such information in SGML documents by declaring each image as an external entity encoded in a suitable non-SGML notation, and then referring to it from within the document.

In addition to graphic images, documents often contain material presented in graphical or tabular format. In such materials, details of layout and presentation may also be of comparatively greater significance or complexity than they are for running text. Indeed, it may often be difficult to make a clear distinction between details relating purely to the rendition of information and those relating to the information itself.

Finally, documents may contain mathematical formulæ or expressions in other formulaic notations, for which no SGML notation is defined in these Guidelines.

These areas (graphics, tabular material, and mathematical or other formulæ) have in common that they have received considerable attention from many other standards bodies or similar professional groups. In part because of this, they may frequently be most conveniently encoded and processed using some non-SGML notation, or some SGML notation not defined by these Guidelines. For these reasons, and others, we consider tables, formulæ, and graphics together in this chapter.

As with text markup in general, many incompatible formats have been proposed for the representation of graphics, formulae and tables in electronic form. Unfortunately, no single format as effective as SGML in the domain of text has yet emerged for their interchange, to some extent because of the difficulty of representing the information these data formats convey independently of the way it is rendered.

The additional tag set defined by this chapter defines special purpose container elements that can be used to encapsulate occurrences of such data within a TEI-conformant document in a portable way. Specific recommendations for the encoding of tables are provided in section and recommendations for mathematical or other formulæ in section . Specific recommendations for the encoding of graphic figures may be found in section . The rest of the chapter is devoted to general problems of encoding graphic information.

There is at the time of writing no consensus on formats for graphical images, and such formats vary in many ways. We therefore provide (in section ) a brief discussion of the ways in which images may be represented, and (in section ) a list of formal names for those representations most popular at this time. Each one includes a very brief description and (where known) a reference to the formal specification of the notation. These Guidelines recommend a few particular representations as being the most widely supported and understood.

To enable the additional tag set defined by this chapter, the parameter entity TEI.figures must be defined with the value INCLUDE, as shown in the example below: ]> ]]> With this declaration in effect, the TEI elements and attributes described in the following sections are all available. If any of the specialized notations described in sections and are used, then an additional notation declaration must also be included in the document type declaration subset, as further illustrated below.

The overall structure of the tag set defined in this chapter is as follows: ]]> Tables

A table is the least graphic of the elements discussed in this chapter. Almost any text structure can be presented as a series of rows and columns: one might, for example, choose to show a glossary or other form of list in tabular form, without necessarily regarding it as a table. In such cases, the global rend attribute is an appropriate way of indicating that some element is being presented in tabular format. When tabular presentation is regarded as of less intrinsic importance, it is correspondingly simpler to encode descriptive or functional information about the contents of the table, for example to identify one column as containing names and another as containing dates, though the two methods may be combined.

When, however, particular SGML elements are required to encode the tabular arrangement itself, then one or other of the various table DTDs now available may be preferable. The table DTDs in common use generally view a table as a special text element, made up of row elements (or, sometimes, column elements), themselves composed of cells. Table cells generally appear in row-major order, with the first row from left to right, then the second row, and so on. Details of appearance such as column widths, border lines, and alignment are generally encoded by numerous attributes. Beyond this, however, such DTDs differ greatly. This section begins by describing a table DTD of this kind; a brief summary of some other widely available table DTDs is also provided in section . The TEI Table DTD

For encoding tables of low to moderate complexity, these Guidelines provide the following special purpose elements: table contains text displayed in tabular form, in rows and columns. Attributes include: rows indicates the number of rows in the table. cols indicates the number of columns in each row of the table. row contains one row of a table. Attributes include: role indicates the kind of information held in the cells of this row. Suggested values include: label labelling or descriptive information only. data data values. cell contains one cell of a table. Attributes include: role indicates the kind of information held in the cell. Suggested values include: label labelling or descriptive information only. data data values. cols indicates the number of columns occupied by this cell. rows indicates the number of rows occupied by this cell.

The table element is defined as a member of the class inter; it may therefore appear both within other components (such as paragraphs), or between them, provided that the additional tag set defined in this chapter has been enabled, as described at the beginning of this chapter.

It is to a large extent arbitrary whether a table should be regarded as a series of rows or as a series of columns. For compatibility with currently available systems, however, these Guidelines require a row-by-row description of a table. It is also possible to describe a table simply as a series of cells; this may be useful for tabular material which is not presented as a simple matrix.

The attributes rows and cols may be used to indicate the size of a table, or to indicate that a particular cell of a table spans more than one row or column. For both tables and cells, rows and columns are always given in top-to-bottom, left-to-right order. These Guidelines do not require that the size of a table be specified; for most formatting and many other applications, it will be necessary to process the whole table in two passes in any case.

Where cells span more than one column or row, the encoder must determine whether this is a purely presentational effect (in which case the rend attribute may be more appropriate), whether the part of the table affected would be better treated as a nested table, or whether to use the spanning attributes listed above.

The role attribute may be used to categorize a single cell, or set a default for all the cells in a given row. The present Guidelines distinguish the roles of label and data only, but the encoder may define other roles, such as derived, numeric, etc., as appropriate.

The following simple example demonstrates how the data presented as a labelled list in section might be represented by an encoder wishing to preserve its original appearance as a table: Report of the conduct and progress of Ernest Pontifex. Upper Vth form — half term ending Midsummer 1851 Classics Idle listless and unimproving Mathematics ditto Divinity ditto Conduct in house Orderly General conduct Not satisfactory, on account of his great unpunctuality and inattention to duties ]]>

Note that this encoding makes no attempt to represent the full significance of the ditto cells above; these might be regarded as simple links between the cells containing them and that to which they refer, or as virtual copies of it. For ways of representing either interpretation, see chapter .

The following example demonstrates how a simple statistical table may be represented using this scheme: Poor Man's Lodgings in Norfolk (Mayhew, 1843) Dossing Cribs or Lodging Houses Beds Needys or Nightly Lodgers Bury St Edmund's 58128 Thetford 3636 Attleboro' 3520 Wymondham 11122 ]]>

Note the use of a blank cell in the first row to ensure that the column labels are correctly aligned with the data. Again, this encoding does not explicitly represent the alignment between column and row labels and the data to which they apply. Where the primary emphasis of an encoding is on the semantic content of a table, a more explicit mechanism for the representation of structured information such as that provided by the feature structure mechanism described in chapter may be preferred. Alternatively, the general purpose linkage and alignment mechanisms described in chapter may also be applied to individual cells of a table.

The content of a table cell need not be simply character data. It may also contain any sequence of the phrase level elements described in chapter , thus allowing for the encoding of potentially more useful semantic information, as in the following example, where the fact that one cell contains a number and the other contains a place name has been explicitly recorded: US State populations, 1990 Wyoming 453,588 Alaska 550,043 Vermont 562,758 District of Columbia 606,900 North Dakota 638,800 Delaware 666,168 South Dakota 696,004 Montana 799,065 Rhode Island 1,003,464 ]]>

In syntactic terms this is little more than a name-change; however, the new names are more useful in that they convey something about the nature and significance of the information, rather than merely suggesting how to display it in rows and columns.

The TEI table elements are defined as follows: ]]> Other Table DTDs

Many SGML authoring systems now include built-in support for their own or for public table DTDs. These often provide an enhanced user interface and good formatting capabilities, but are often product-specific, despite their use of SGML.

The SGML DTD developed by the Association of American Publishers (AAP) and standardized in ANSI Z39.59 provided a very simple encoding for correspondingly simple tables. This has been further developed, together with the table DTD documented in ISO Technical Report 9537, and now forms part of ISO 12083. The TEI DTD fragment described above has functionality very similar to that defined by ISO 12083.

For more complex tables, the most effective publically-available DTD is probably that developed by the US Department of Defense CALS project. This supports vertical and horizontal spanning and various kinds of text rotation and justification within cells and is also directly supported by a number of existing SGML software systems.

The CALS table DTD is much too complex to describe fully here; information on it can be obtained, among other places, from the Graphic Communications Association in Alexandria, Virginia. The formal name of the CALS SGML requirements is MIL-M-28001A. Tables conforming to the CALS DTD may be incorporated into documents conforming to these Guidelines, but this may require substantial modification of the TEI DTD which should not be undertaken without expert advice. Formulae

Mathematical and chemical formulæ pose similar problems to those posed by tables in that rendition may be of great significance and hard to disentangle from content. They also require access to a wide range of special characters, for most of which standard entity names already exist in the documented ISO entity sets (see further chapters and ).

Formulæ and tables are also similar in that well-researched and detailed SGML DTD fragments have already been developed for them independently of the TEI. They differ in that (for mathematics at least) there also exists a richly detailed text-based but non-SGML notation which is very widely used: this is the TeX system, and the sets of descriptive macros developed for it such as LaTeX and AMS-Tex.

The AAP and ISO standards mentioned in section above both provide SGML DTDs for equations as well as for tables, which at the time of writing are being updated and unified to form part of ISO 12083. There is also also a third and more general-purpose ongoing mathematical DTD effort known as EuroMath.

As with tables, in all the SGML solutions a tension exists between the need to encode the way a formula is written (its appearance) and the need to represent its semantics. If the object of the SGML encoding is purely to act as an interchange format among different formatting programs, then there is no need to represent the mathematical meaning of an expression. If however the object is to use the SGML encoding as input to an algebraic manipulation system (such as Mathematica or Maple) or a database system, clearly simply representing superscripts and subscripts will be inadequate.

The present Guidelines make no attempt to add to the number of available DTDs for representing formulæ. Instead, we recommend that the user make an informed choice from those already available. The additional tag set described in this chapter makes available only the following element, which should be used to encode any formula, no matter what notation is employed: formula contains a mathematical or other formula. Attributes include: notation supplies the name of a previously defined notation used for the content of the element.

The legal content of a formula is determined by two factors. The parameter entity formulaContent supplies an SGML content model for the element; while the notation attribute specifies what SGML notation is employed by the element. The default value of the formulaContent entity is CDATA, but may be redefined in the document's DTD subset, for example as follows: ]]> With this declaration in force, formulæ may contain parsed character data, (and may thus use SGML entity references for special symbols and the like). An alternative might be to embed the elements defined by some other tag set, such as that of ISO 12083. In this case additional redefinitions may also be needed to avoid name clashes with existing TEI elements. For further details see chapter .

Secondly, when it is necessary to inform an SGML processor that the content of a formula should not be treated as ordinary SGML data, because it uses a different notation, a notation must be specified. Each notation used by a document must be declared in its DTD subset, as in the following example: ]> ]]>

With these declarations in force, a document may include formulæ expressed using standard TeX conventions, as in the following example: Achilles runs ten times faster than the tortoise and gives the animal a headstart of ten meters. Achilles runs those ten meters, the tortoise one; Achilles runs that meter, the tortoise runs a decimeter; Achilles runs that decimeter, the tortoise runs a centimeter; Achilles runs that centimeter, the tortoise, a millimeter; Fleet-footed Achilles, the millimeter, the tortoise, a tenth of a millimeter, and so on to infinity, without the tortoise ever being overtaken. . . Such is the customary version. The problem does not change, as you can see; but I would like to know the name of the poet who provided it with a hero and a tortoise. To those magical competitors and to the series $$ {1 \over 10} + {1 \over 100} + {1 \over 1000} + {1 \over 1000} + {1 \over 10,\!000} + \dots $$ the argument owes its fame. ]]> The notation attribute supplies the name of a defined SGML notation (LaTeX), which is associated by its declaration in the DTD subset with an external public entity. How that declaration is resolved will depend on the kind of processor in use, and is outside the scope of these Guidelines. The declaration for the formulaContent parameter entity in the DTD will determine how the contents of any formula elements will first be parsed by the SGML processor before they are handed to whatever procedure is intended to handle the external notation. When as here it is declared with a value of (#PCDATA), then any SGML entity references in the content will be resolved. This may be useful if the external mechanism uses characters which would otherwise be regarded as significant to the SGML processor: for example, the less-than or greater-than signs. If a less-than sign or another SGML delimiter occurs in a context meaningful to SGML (for the most common delimiters this mean before any letter), the SGML processor will attempt to interpret it: For example, in this expression: a ]]> because the less-than sign is followed by a letter, it would be recognized by SGML as beginning a start-tag (for a presumably nonexistent element b). One way of avoiding this problem is to represent the less-than character by an entity reference: a<b ]]>

Of course, if the notation permits it (as TeX does), a simpler solution to this specific problem is to insert a space after the less-than sign: a < b ]]> Entity references may only appear in the content of a formula element when the entity formulaContent has been redefined as above. By default, formulaContent is defined as CDATA, which means that the only SGML processing carried out is to search for an end-tag. This means that the character sequence </ may not be followed by a > or a letter anywhere within a formula; outside an SGML context, this sequence is fairly unlikely. If it does appear, or if an SGML notation is used, then the parameter entity must be redefined appropriately.

The following SGML-based notations for encoding formulæ are recommended by these Guidelines: ]]>

In-line versus block placement for an equation can be distinguished if desired, via the global rend attribute. The global n and id attributes may also be used to label or identify the formula, as in the following (imaginary) example: The volume of a sphere is given by the formula: $$V = {4\over 3} \pi r^3$$ which is readily calculated.