<!-- $Id: p2ft.odd,v 1.9 1998/01/31 19:50:52 tei Exp $ -->
<!--*
    * $Log: p2ft.odd,v $
    * Revision 1.9  1998/01/31 19:50:52  tei
    * Change system 'tei2.dtd' to public identifier
    * fix log keyword (if not already fixed)
    * normalize the sgml
    *
    * Revision 1.8  94/04/08  18:54:36  msmcq
    * Last-second fixes for P3
    *
    * Revision 1.7  1994/03/21  14:12:08  lou
    * second mass typo clearup
    *
    * Revision 1.4  1994/03/07  15:31:52  lou
    * apply various typos etc.
    *
    * Revision 1.3  1994/03/01  03:56:59  msmcq
    * revision during/after SC meeting
    * -->
<!-- 17 mar: apply MSM's typos of 8 mar -->
<!-- 13 mar: change id opn dtdfrag to avoid id clash -->
<!-- To do:                                                   -->
<!-- biblio for z39.59, iso 12085, iso 9573, cals /milspec 28001 -->
<!-- biblio for LaTeX, AMS-TeX                                -->
<!-- rename formula notn att as notation,                     -->
<!--      make declared value a TEI keyword                   -->
<!-- biblio for Euromath                                      -->
<!-- check on FPIs for Euromath, ISO 9573, ISO 12083          -->
<!-- Revisions:                                               -->
<!-- 94-04-07 : MSM : normalize caps in headings              -->
<!-- 94-02-25 : MSM : add top-level DTD fragment              -->
<!-- 94-02-25 : MSM : comment out list of things to do        -->
<!-- 94-02-25 : MSM : remove items completed                  -->
<!-- 22 Feb 94 : MSM : final cleanup for P3 (first pass)     -->
<!-- 2 feb 94: revised tables extensively: split into chunks -->
<!-- 12 Nov 93: expanded tables -->
<!-- Date: Fri, 25 Jun 1993 17:27:07 -0500 -->
<!-- to: u35395@uicvm.uic.edu, lou@vax.ox.ac.uk, dgd@cs.bu.edu -->
<!-- From: sjd@ebt.com -->

<div1 id="FT" n="22"><head>Tables, Formulae, and Graphics</head>

<p>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.</p>

<p>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.</p>

<p>Finally, documents may contain mathematical formul&aelig; or
expressions in other formulaic notations, for which no SGML notation is
defined in these Guidelines.</p>

<p>These areas (graphics, tabular material, and mathematical or other
formul&aelig;) 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&aelig;, and graphics together in this
chapter.</p>

<p>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.</p>

<p>The additional tag set defined by this chapter defines special
purpose <socalled>container</socalled> 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 <ptr target="FTtab"> and recommendations for
mathematical or other formul&aelig; in section <ptr target="FTfor">.
Specific recommendations for the encoding of graphic figures may be
found in section <ptr target="FTgra">.  The rest of the chapter is
devoted to general problems of encoding graphic information.</p>

<p>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 <ptr target="FTgrov">) a brief discussion of the ways in which
images may be represented, and (in section <ptr target="FTgrno">) 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.</p>

<p>To enable the additional tag set defined by this chapter, the
parameter entity <term>TEI.figures</term> must be defined with the
value <code>INCLUDE</code>, as shown in the example below:

<eg>
<![ CDATA [
 <!DOCTYPE tei.2 PUBLIC "-//TEI P3//DTD Main Document Type//EN"
                        "tei2.dtd" [
    <!ENTITY % TEI.figures 'INCLUDE' >
 ]>
]]>
</eg>

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 <ptr target="FTfor"> and
<ptr target="FTgra"> are used, then an additional <term>notation
declaration</term> must also be included in the document type
declaration subset, as further illustrated below.

<!-- is this right? we don't have any way of generating notation      -->
<!-- declarations in the tagset anyway, so it will have to be!  (LB) --></p>

<p>The overall structure of the tag set defined in this chapter is
as follows:
<eg id=dftff>
<![ CDATA [
<!-- 22:  Tables, Formulae, Figures                           -->
<!-- ... declarations from section 22.1.1                     -->
<!--     (Tables)                                             -->
<!--     go here ...                                          -->
<!-- ... declarations from section 22.2                       -->
<!--     (Formulae)                                           -->
<!--     go here ...                                          -->
<!-- ... declarations from section 22.3                       -->
<!--     (Figures)                                            -->
<!--     go here ...                                          -->
]]>
</eg>

</p>

<!-- $Id: p2fttab.odd,v 1.3 1994/03/07 15:31:52 lou Exp $ -->
<!-- $Log: p2fttab.odd,v $
# Revision 1.3  1994/03/07  15:31:52  lou
# apply various typos etc.
#
# Revision 1.2  1994/03/01  03:56:59  msmcq
# revision during/after SC meeting
# -->
<!-- Revisions:                                               -->
<!-- 1994-02-23 : MSM : cleanup for TEI P3                    -->

<div2 id=FTtab><head>Tables</head>

<p>A table is the least <soCalled>graphic</soCalled> 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 <att>rend</att>
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.

<p>When, however, particular SGML elements are required to encode the
tabular arrangement itself, then one or other of the various
<soCalled>table DTDs</socalled> 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 <ptr target=FTtab2>.

<div3 id=FTtab1><head>The TEI Table DTD</head>

<p>For encoding tables of low to moderate complexity, these Guidelines
provide the following special purpose elements:

<list type=gloss>
<label><gi>table</gi></label>
<item>contains text displayed in tabular form, in
rows and 
columns.
Attributes include:
<list type=gloss>
<label><att>rows</att></label>
<item>indicates the number of rows in the table.</item>
<label><att>cols</att></label>
<item>indicates the number of columns in each row of the table.</item>
</list>
</item>
<label><gi>row</gi></label>
<item>contains one row of a table. 
Attributes include:
<list type=gloss>
<label><att>role</att></label>
<item>indicates the kind of information held in the cells of this 
row.
Suggested values include:
<list type=gloss>
<label><term>label</term></label>
<item>labelling or descriptive information only.</item>
<label><term>data</term></label>
<item>data values.</item>
</list></item>
</list>
</item>
<label><gi>cell</gi></label>
<item>contains one cell of a table. 
Attributes include:
<list type=gloss>
<label><att>role</att></label>
<item>indicates the kind of information held in the cell.
Suggested values include:
<list type=gloss>
<label><term>label</term></label>
<item>labelling or descriptive information only.</item>
<label><term>data</term></label>
<item>data values.</item>
</list></item>
<label><att>cols</att></label>
<item>indicates the number of columns occupied by this cell.</item>
<label><att>rows</att></label>
<item>indicates the number of rows occupied by this cell.</item>
</list>
</item>
</list>


<p>The <gi>table</gi> element is defined as a member of the class
<term>inter</term>; 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.

<p>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.

<p>The attributes <att>rows</att> and <att>cols</att> 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.

<p>Where cells span more than one column or row, the encoder must
determine whether this is a purely presentational effect (in which case
the <att>rend</att> 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.

<p>The <att>role</att> 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 <term>label</term> and
<term>data</term> only, but the encoder may define other roles, such as
<q>derived</q>, <q>numeric</q>, etc., as appropriate.

<p>The following simple example demonstrates how the data presented as a
labelled list in section <ptr target=COli> might be represented by an
encoder wishing to preserve its original appearance as a table:

<eg>
<![ CDATA [
<table rows=2 cols=2 rend=boxed>
<head rend=it>Report of the conduct and progress
of Ernest Pontifex.  Upper Vth form &mdash; half
term ending Midsummer 1851</head>
<row><cell role=label>Classics</cell>
     <cell>Idle listless and unimproving</cell>
</row>
<row><cell role=label>Mathematics</cell>
     <cell>ditto</cell>
</row>
<row><cell role=label>Divinity</cell>
     <cell>ditto</cell>
</row>
<row><cell role=label>Conduct in house</cell>
      <cell>Orderly</cell>
</row>
<row><cell role=label>General conduct</cell>
     <cell>Not satisfactory, on account of his great
     unpunctuality and inattention to duties</cell>
</row></table>
]]>
</eg><!-- S Butler, Way of all Flesh, -->

<p>Note that this encoding makes no attempt to represent the full
significance of the <q>ditto</q> 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 <ptr target=SA>.

<p>The following example demonstrates how a simple statistical table may
be represented using this scheme:

<eg>
<![ CDATA [
<table rows=4 cols=4>
<head>Poor Man's Lodgings in Norfolk (Mayhew, 1843)
<row role=label>
  <cell>
  <cell>Dossing Cribs or Lodging Houses
  <cell>Beds
  <cell>Needys or Nightly Lodgers
<row role=data>
  <cell role=label>Bury St Edmund's
  <cell>5<cell>8<cell>128
<row role=data>
  <cell role=label>Thetford
  <cell>3<cell>6<cell>36
<row role=data>
  <cell role=label>Attleboro'
  <cell>3<cell>5<cell>20
<row role=data>
  <cell role=label>Wymondham
  <cell>1<cell>11<cell>22
<!-- ... -->
</table>
]]>
</eg>

<p>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 <ptr
target=FS> may be preferred.  Alternatively, the general purpose linkage
and alignment mechanisms described in chapter <ptr target=SA> may also
be applied to individual cells of a table.

<p>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 <ptr target=CO>, 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:

<eg>
<![ CDATA [
<TABLE>
   <head>US State populations, 1990</head>
   <row role=data>
        <cell><name>Wyoming</>
        <cell><num>453,588</></row>
   <row><cell><name>Alaska</>
        <cell><num>550,043</></row>
   <row><cell><name>Vermont</>
        <cell><num>562,758</></row>
   <row><cell><name>District of Columbia</>
        <cell><num>606,900</></row>
   <row><cell><name>North Dakota</>
        <cell><num>638,800</></row>
   <row><cell><name>Delaware</>
        <cell><num>666,168</></row>
   <row><cell><name>South Dakota</>
        <cell><num>696,004</></row>
   <row><cell><name>Montana</>
        <cell><num>799,065</></row>
   <row><cell><name>Rhode Island</>
        <cell><num>1,003,464</></row>
  <!-- ... -->
</table>
]]>
</eg>

<p>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.</p>

<p>The TEI table elements are defined as follows:
<eg id=dfttab>
<![ CDATA [
<!-- 22.1.1:  Tables                                          -->
<!ELEMENT table         - -  (head*, row+)                      >
<!ATTLIST table              %a.global;
          rows               NUMBER              #IMPLIED
          cols               NUMBER              #IMPLIED       >
<!ELEMENT row           - O  ((cell | table)+)                  >
<!ATTLIST row                %a.global;
          role               CDATA               data           >
<!ELEMENT cell          - O  (%paraContent)                     >
<!ATTLIST cell               %a.global;
          role               CDATA               data
          rows               NUMBER              1
          cols               NUMBER              1              >
<!-- This fragment is used in sec. 22                         -->
]]>
</eg>


<div3 id=FTtab2><head>Other Table DTDs</head>

<p>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.

<p>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.

<!-- need proper bibliog refs for these -->

<p>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.

<p>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.

<!-- need proper biblio reference here -->

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.

</div2>


<!-- $Id: p2ftfor.odd,v 1.5 1994/04/08 18:54:36 msmcq Exp $ -->
<!-- $Log: p2ftfor.odd,v $
# Revision 1.5  1994/04/08  18:54:36  msmcq
# Last-second fixes for P3
#
# Revision 1.4  1994/03/21  14:12:09  lou
# second mass typo clearup
#
# Revision 1.3  1994/03/07  15:31:52  lou
# apply various typos etc.
#
# Revision 1.2  1994/03/01  03:56:59  msmcq
# revision during/after SC meeting
# -->
<!-- Revisions:                                               -->
<!-- 94-04-07 : MSM : respell heading                         -->
<!-- 94-02-28 : MSM : refine TeX expressions                  -->
<!-- 94-02-28 : MSM : Replace sphere with Borges              -->
<!-- 94-02-28 : MSM : correct other instance of sphere        -->
<!-- 94-02-25 : MSM : suppress FILE att on dtdfrag            -->
<!-- 94-02-25 : MSM : fix minor SGML glitches                 -->
<!-- 1994-02-23 : MSM : revise for style, try to fix FPIs     -->

<div2 id=FTfor><head>Formulae</head>

<p>Mathematical and chemical formul&aelig; 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
<ptr target=CH> and <ptr target=WD>).

<p>Formul&aelig 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.

<!-- refs for all these are needed -->

<p>The AAP and ISO standards mentioned in section <ptr target=FTtab>
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.<note>Reference needed!
FIX THIS NOTE BEFORE PUBLICATION.
FIX THIS NOTE BEFORE PUBLICATION.
FIX THIS NOTE BEFORE PUBLICATION.
FIX THIS NOTE BEFORE PUBLICATION.
FIX THIS NOTE BEFORE PUBLICATION.
FIX THIS NOTE BEFORE PUBLICATION.
FIX THIS NOTE BEFORE PUBLICATION.
FIX THIS NOTE BEFORE PUBLICATION.
</note>

<p>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.

<p>The present Guidelines make no attempt to add to the number of
available DTDs for representing formul&aelig;.  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:

<list type=gloss>
<label><gi>formula</gi></label>
<item>contains a mathematical or other formula.
Attributes include:
<list type=gloss>
<label><att>notation</att></label>
<item>supplies the name of a previously defined notation used for 
the content of the element.</item>
</list>
</item>
</list>


<p>The legal content of a <gi>formula</gi> is determined by two factors.
The parameter entity <term>formulaContent</term> supplies an SGML
content model for the element; while the <att>notation</att> attribute
specifies what SGML <term>notation</term> is employed by the element.
The default value of the <term>formulaContent</term> entity is
<code>CDATA</code>, but may be redefined in the document's DTD subset, for
example as follows:

<eg>
<![ CDATA [
<!ENTITY % formulaContent "(#PCDATA)">
]]>
</eg>

With this declaration in force, formul&aelig; 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.  <note
place=foot>In this case additional redefinitions may also be needed to
avoid name clashes with existing TEI elements.  For further details see
chapter <ptr target=MD>.</note>

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

<eg>
<![ CDATA [
 <!DOCTYPE tei.2 [
 <!ENTITY % TEI.graphics "INCLUDE">
 <!NOTATION TeX PUBLIC
   '-//Donald E. Knuth 1983//NOTATION TeX Mathematical Markup//EN'>
 <!ENTITY % formulaContent "(#PCDATA)"  >
 ]>
]]>
</eg>

<p>With these declarations in force, a document may include formul&aelig;
expressed using standard TeX conventions, as in the following example:

<eg>
<![ CDATA [
<p>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
<formula notation=TeX>
$$
{1 \over 10} +
{1 \over 100} +
{1 \over 1000} +
{1 \over 1000} +
{1 \over 10,\!000} +
\dots
$$
</formula>
the argument owes its fame.
]]>
</eg>
<!-- Jorge Luis Borges, "Avatars of the Tortoise," transl.    -->
<!-- James E. Irby, in <title>Labyrinths:  Selected Stories   -->
<!-- and Other Writings</title> ([New York]:  New             -->
<!-- Directions, 1962), pp. 202-203.                          -->

The <att>notation</att> attribute supplies the name of a defined SGML
notation (<q>LaTeX</q>), 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
<term>formulaContent</term> parameter entity in the DTD will determine
how the contents of any <gi>formula</gi> 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 <code lang=sgml type=fragment>(#PCDATA)</code>, 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:

<eg><![ CDATA [
<formula notation=tex> a<b </formula>
]]>
</eg>

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 <gi tei=no>b</gi>).  One way of avoiding this
problem is to represent the less-than character by an entity reference:

<eg><![ CDATA [
<formula notation=tex> a&lt;b </formula>
]]>
</eg>

<p>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:

<eg><![ CDATA [
<formula notation=tex> a < b </formula>
]]>
</eg>

Entity references may only appear in the content of a <gi>formula</gi>
element when the entity <term>formulaContent</term> has been redefined
as above.  By default, <term>formulaContent</term> is defined as
<code>CDATA</code>, which means that the only SGML processing carried
out is to search for an end-tag.  This means that the character sequence
<code>&lt;/</code> may not be followed by a <code>></code> 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.

<p>The following SGML-based notations for encoding formul&aelig; are
recommended by these Guidelines:

<eg>
<![ CDATA [
<!NOTATION iso12083 PUBLIC
   'ISO 12083:1993//DTD Formulae//EN'>
<!NOTATION euromath PUBLIC
   '-//Euromath 1992//DTD Euromath equations//EN'>
]]>
</eg>


<p>In-line versus block placement for an equation can be distinguished
if desired, via the global <att>rend</att> attribute.  The global
<att>n</att> and <att>id</att> attributes may also be used to label or
identify the formula, as in the following (imaginary) example:

<eg>
<![ CDATA [
<p>The volume of a sphere is given by the formula:
<formula n=12 rend=inline id=F12 notation=tex>
   $$V = {4\over 3} \pi r^3$$
</formula>
which is readily calculated.
</p>
<p>
As we have seen in equation <ptr target=F12>, ....

]]>
</eg>


<p>The <term>formulaContent</term> and <term>formulaNotations</term>
parameter entities are defined as follows:

<eg id=dftpe>
<![ CDATA [
<!-- 22.2:  Formula Content                                   -->
<!ENTITY % formulaNotations 'CDATA'                             >
<!ENTITY % formulaContent 'CDATA'                               >
]]>
</eg>


<p>The formula element itself is defined as follows:

<eg id=dftfor>
<![ CDATA [
<!-- 22.2:  Formulae                                          -->
<!ELEMENT formula       - -  %formulaContent;                   >
<!ATTLIST formula            %a.global;
          notation           %formulaNotations   #REQUIRED      >
<!-- This fragment is used in sec. 22                         -->
]]>
</eg>


</div2>


<!-- $Id: p2ftgra.odd,v 1.6 1998/01/31 19:14:05 tei Exp $ -->
<!--*
    * $Log: p2ftgra.odd,v $
    * Revision 1.6  1998/01/31 19:14:05  tei
    * Use public identifiers, not system identifiers.
    *
    * Revision 1.5  98/01/31  17:17:18  tei
    * Fix log keyword
    *
    * Revision 1.4  94/03/21  14:12:09  lou
    * second mass typo clearup
    *
    * Revision 1.3  1994/03/07  15:31:52  lou
    * apply various typos etc.
    *
    * Revision 1.2  1994/03/01  03:56:59  msmcq
    * revision during/after SC meeting
    *-->
<!-- Revisions:                                               -->
<!-- 98-01-31 : MSM : fix owner identifiers in public ids     -->
<!-- 98-01-30 : MSM : fix references to 'system entities';    -->
<!--                  make them 'external entities' instead   -->
<!-- 94-02-28 : MSM : no NOTATION att on FIGURE element       -->
<!-- 94-02-25 : MSM : upgrade ISO fpis                        -->
<!-- 94-02-25 : MSM : add example of long caption             -->
<div2 id="FTgra"><head>Specific Elements for Graphic Images</head>

<p>The following special purpose elements are provided by this
tag set to indicate the presence of graphic images within a document:

<list type=gloss>
<label><gi>figure</gi></label>
<item>indicates the location of a graphic, illustration, or 
figure.
Attributes include:
<list type=gloss>
<label><att>entity</att></label>
<item>names the external entity within which the graphic image of 
the figure is stored.</item>
</list>
</item>
<label><gi>figDesc</gi></label>
<item>contains a brief prose description of the appearance or 
content
of a graphic figure, for use when documenting an 
image without
displaying it.</item>
</list>
</p>

<p>Inclusion of a graphic image in an SGML document of any kind
typically requires three distinct steps:

<list type="ordered">

<item>The <term>notation</term> employed by the image itself must be
defined; this is done with an SGML notation declaration in the document
type definition.</item>

<item>The external entity in which the image is stored must be defined;
this is done with an SGML entity declaration, which refers to the
notation declared at step one.</item>

<item>Within the document, the <gi>figure</gi> element is used to mark
the position of the image, which is referenced by name, like any other
kind of external entity.</item>

</list>

In the TEI scheme, these three functions are carried out as follows.</p>

<p>Declarations for all notations used by a document must be provided
within the DTD subset, as described above in section <ptr
target="FTfor">.  Many such notations are in common use; for details see
section <ptr target="FTgrno">.</p>

<p>Entity declarations for the entities containing the
graphics themselves must be made, using system or public identiifers,
within the document's DTD subset,
either directly or by including them within a suitable file, as in the
example below.

<eg>
<![ CDATA [
<!DOCTYPE tei.2 PUBLIC "-//TEI P3//DTD Main Document Type//EN"
                       "tei2.dtd" [
<!ENTITY % TEI.prose "INCLUDE">
<!ENTITY % TEI.graphics "INCLUDE">

<!-- Graphics notations used in this document ... -->
<!NOTATION tiff PUBLIC
    '-//TEI//NOTATION Aldus Tagged Image File Format//EN' >
<!NOTATION cgm PUBLIC
    'ISO 8632-4:1987//NOTATION Clear text encoding//EN' >
<!NOTATION bmp  PUBLIC
    '-//TEI//NOTATION BMP:  Microsoft Bitmapped graphic
               format//EN' >


<!-- The file 'figures.ent' contains entity declarations -->
<!-- for all external entities needed by this document -->
<!ENTITY % myFigures "figures.ent"> %myFigures;
]>
]]>
</eg>

The file <term>figures.ent</term> will contain a series of
declarations like the following:

<eg>
<![ CDATA [
<!ENTITY Fig1    system  "fig1.cgm"    NDATA cgm>
<!ENTITY Fig1th  system  "fig1.bmp"    NDATA bmp>
<!ENTITY pullman system  "pullman.tif" NDATA tiff>
]]>
</eg>

the effect of which is to associate the name <term>Fig1</term> with the
external entity <term>fig1.cgm</term>, and also to declare that that
entity uses the non-SGML notation called <q>CGM</q>, which is declared
in the DTD subset.  In the same way, the external entity
<term>fig1.bmp</term> is defined as using the <q>BMP</q> notation, and
may be referenced by the name <term>Fig1th</term> (see further below).</p>

<p>Finally, the <gi>figure</gi> element is used to indicate the location
of the graphic image in the text.  For example:

<eg>
<![ CDATA [
<figure entity='Fig1'></figure>
]]>
</eg>
</p>
<!-- Use a Tenniel Alice drawing?  Or a Holmes piece.         -->

<p>Note that an end-tag is always required for this element.  Three
kinds of content may be supplied: the element <gi>head</gi> may be
used to transcribe (or supply) a descriptive heading or title for the
graphic itself as in this example:

<eg>
<![ CDATA [
<figure entity='Fig1'>
<head>Figure One: The View from the Bridge</head></figure>
]]>
</eg></p>

<p>Figures are often accompanied not only by a title or heading, but
by a paragraph or so of commentary or caption.  One or more <gi>p</gi>
elements following the <gi>head</gi> may be used to transcribe any
caption or discussion of the figure in the source:

<eg>
<![ CDATA [
<figure entity=pullman>
<head>Above:</head>
<p>The drawing room of the Pullman house, the white and
gold saloon where the magnate delighted in giving
receptions for several hundred people.</p>
<figDesc>The figure shows an elaborately decorated room,
at least twenty-five feet side to side and fifty feet
long, with ornate mouldings and Corinthian columns
on the walls, overstuffed armchairs and loveseats
arranged in several conversational groupings, and
two large chandeliers.</figDesc>
</figure>
]]>
</eg>
<!-- David Lowe, Lost Chicago (Boston:  Houghton Mifflin, 1978), -->
<!-- p. 30 top.  Ex libris Wendy Plotkin.                     -->

Here, the paragraph <q>The drawing room ... several hundred people</q>
is transcribed from the source, while the description is provided by
the encoder, for use by applications which cannot display the graphic
directly.  In documents created in electronic form with the needs of
print-handicapped readers in mind, the <gi>figDesc</gi> element may be
provided by the author rather than a subsequent encoder.

<eg>
<![ CDATA [
<figure entity='Fig1'>
<head>Figure One: The View from the Bridge</head>
<figDesc>A Whistleresque view showing four
or five sailing boats in the foreground, and a
series of buoys strung out between them.</figDesc>
</figure>
]]>
</eg></p>

<p>Where the graphic itself contains large amounts of text, perhaps
with a complex structure, and perhaps difficult to distinguish from
the graphic, the encoder should choose whether to regard the graphic
as containing the text (in which case, a nested <gi>text</gi> element
may be included within the <gi>figure</gi> element) or to regard the
enclosed text as being a separate division of the <gi>text</gi>
element in which the graphic appears.  In this latter case, an
appropriate <term>divn</term> class element may be used for the text
represented within the graphic, and the <gi>figure</gi> element
embedded within it.  The choice will depend to a large degree on the
encoder's understanding of the relationship between the graphic and
the surrounding text.</p>

<p>Like any other element in the TEI scheme, figures may be given
identifiers so that they can be aligned with other elements, and linked
to or from them, as described in chapter <ptr target="SA">.  Some common
examples are discussed briefly here;  full information is provided in
that chapter.</p>

<p>It is often desirable to maintain two versions of an image in an
electronic file:  one a low resolution or <socalled>thumbnail</socalled>
version which, when selected by the user, causes the other, high
resolution, version to be accessed.  In TEI terms, the thumbnail image
acts as a <term>reference</term> to the other.  Referring to the example
above, we will assume that the entity <q>Fig1th</q> contains a thumbnail
version of the full Fig1 entity.  We can now embed a reference to that
image using the simple <gi>ref</gi> element discussed in section <ptr
target="COxr">:

<eg>
<![ CDATA [

<ref target=im1>Click here
    <figure entity=fig1th></>
     for enlightenment
</ref>
<!-- ... -->
<!-- elsewhere in the document -->
<figure id=im1 entity=fig1></>
<!-- other figures here -->
]]>
</eg></p>

<p>Another common requirement is to associate part or the whole of an
image with a textual element not necessarily contiguous to it in the
text; this is sometimes known as a <term>callout</term>. Again, chapter
<ptr target="SA"> should be consulted for the full details of the
mechanisms available for this purpose. This example assumes that we wish
to associate one portion of the image held as <q>fig1</q> with chapter
two of some text, and another portion of it with chapter three. The
application may be thought of as a hypertext browser in which the user
selects from a graphic image which part of a text to read next, but the
mechanism is independent of this particular application.</p>

<p>The first requirement is some way of identifying and hence pointing
to sub-parts of a graphic image. This is most easily done using the
extended pointer syntax discussed in section <ptr target="SAxr">: thus

<eg>
<![ CDATA [
<xptr id=pd1 doc=Fig1 from='space (0 0 9 9)'>
<xptr id=pd2 doc=Fig1 from='space (40 90 59 119)'>
]]>
</eg></p>

<p>These <gi>xptr</gi> elements identify two areas within the image
<q>Fig1</q> using the TEI extended pointer syntax.  The first (with
identifier <q>pd1</q>) is a square of size 10 by 10, tangent to the
origin.  The second (with identifier <q>pd2</q>) is a rectangle of size
20 by 30, starting at the point with co-ordinates (40,90) in the
co-ordinate system used by this document.</p>

<p>The next requirement is some way of identifying the parts of the
document to which a link is to be made.  The most obvious way of doing
this is to use the global <att>id</att> attribute:

<eg>
<![ CDATA [
<div1 type=chapter id=C1>
  <!-- text of chapter one here -->
<div1 type=chapter id=C2>
  <!-- text of chapter two here -->

]]>
</eg></p>

<p>Now, all that is needed to linking these areas to the relevant
chapters is a <gi>linkGrp</gi> element, as described in section <ptr
target="SApt">:

<eg>
<![ CDATA [
<linkGrp type=callout>
  <link targets='C1 pd1'>
  <link targets='C2 pd2'>
  <!-- ... -->
</linkGrp>

]]>
</eg>

Further examples of this technique are provided in chapter <ptr
target="SA">.</p>


<p>The elements discussed in this section are defined as follows:

<eg id=dftgra>
<![ CDATA [
<!-- 22.3:  Figures                                           -->
<!ELEMENT figure        - -  (head?, p*, figDesc?, text?)       >
<!ATTLIST figure             %a.global;
          entity             ENTITY              #IMPLIED       >
<!ELEMENT figDesc       - -  (%paraContent;)                    >
<!ATTLIST figDesc            %a.global;                         >
<!-- This fragment is used in sec. 22                         -->
]]>
</eg>

</p></div2>

<div2 id="FTgrov"><head>Overview of Basic Graphics Concepts</head>

<!-- could put in a ref to Peter R's nice book here? -->

<p>The first major distinction in graphic representation is that between
raster graphics and vector graphics.  A <term>raster image</term> is a
list of points, or dots.  Scanners, fax machines and other simple
devices easily produce digital raster images, and such images are
therefore quite common.  A <term>vector image</term>, in contrast, is a
list of geometrical objects, such as lines, circles, arcs, or even
cubes.  These are much more difficult to produce, and so are mainly
encountered as the output of sophisticated systems such as architectural
and engineering CAD programs.</p>

<p>Raster images are difficult to modify because by definition they only
encode single points:  a line, for example, cannot grow or shrink as
such, since it is not identified as such.  Only its component parts are
identified, and only they can be manipulated.  Therefore the resolution
or dot-size of a raster image is important, which is not the case with
vector images.  It is also far more difficult to convert raster images
to vector images than to perform the opposite conversion.  Raster images
generally require more storage space than vector images, and a wide
variety of methods exists for compressing them; the variation in these
methods leads to corresponding variations in representations for storage
and transmission of raster images.</p>

<p>Motion video usually consists of a long series of raster images.
Data compression is even more effective on video than on single raster
images (mainly owing to redundancy which arises from the usual similarity
of adjacent frames).  Notations for representing full-motion video
are hotly debated at this time, and any user of these Guidelines would
do well to obtain up-to-date expert advice before undertaking a project
using them.</p>

<p>The compression methods used with any of these image types may be
<socalled>lossy</socalled> or <socalled>lossless</socalled>.  Methods
for <term>lossy compression</term> save space by discarding a small
portion of the image's detail, such as fine distinctions of shading.
When decompressed, therefore, such an image will be only a close
approximation of the original.  In contrast, <term>lossless
compression</term> guarantees that the exact uncompressed image will be
reproducible from the compressed form:  only truly redundant information
is removed.  In general, therefore, lossless compression does not save
quite so much space as lossy compression, though it does guarantee
fidelity to the original uncompressed image.</p>

<p>Raster images may be characterized by their <term>resolution</term>,
which is the number of dots per inch used to represent the image.
Doubling the resolution will give a more precise image, but also
quadruple the storage requirement (before compression), and affect
processing time for any operations to be performed, such as displaying
an image for a reader.  Motion video also has resolution in time:  the
number of frames to be shown per second.  Encoders should consider
carefully what resolution(s) and frame rate(s) to use for particular
applications; these Guidelines express no recommendation in this matter,
save the universal ones of consistency and documentation.</p>

<p>Within any image, it is typical to refer to locations via Cartesian
co-ordinate axes:  values for x, y, and sometimes z and/or time.  These
Guidelines provide for this via the <code type="kw">SPACE</code> keyword
of the extended pointing mechanism discussed in section <ptr
target="Saxr">.  However, graphic notations vary in whether co-ordinates
count from left-to-right and top-to-bottom, or another way.  They also
vary in whether co-ordinates are considered real (inches, millimeters,
and so on), or virtual (dots).  These Guidelines do not recommend any of
these methods over another, but all decisions made should be applied
consistently, and documented in the <gi>encodingDesc</gi> section of the
TEI header.<note>No special purpose element is provided for this purpose
by the current version of the Guidelines.  The information should be
provided as one or more distinct paragraphs at the end of the
<gi>encDecl</gi> element described in section <ptr target="HD5">.</note>
</p>

<p>The way in which the color of an image is rendered also varies
greatly.  In monochrome images every displayed point is either black or
white.  In <term>gray-scale</term> images, each point is rendered in
some shade of gray, the number of shades varying from system to system.
In true polychrome images, points are rendered in different colours,
again with varying limitations affecting the number of distinct shades
and the means by which they are displayed.</p></div2>


<div2 id="FTgrno"><head>Graphic Image Formats</head>

<p>As noted above, there exists a bewildering variety of different
graphics formats, and the following list is in no way exhaustive.
Moreover, inclusion of any format in this list should not be taken as
indicating endorsement by the TEI of this format or any products
associated with it.  With the exception of CGM, all the formats listed
here are proprietary to a greater or lesser extent and cannot therefore
be regarded as standards in any meaningful sense.  They are however
widely used by many different vendors.</p>

<p>The following formats are widely used at the present time, and likely to
remain supported by more than one vendor's software:

<list>
<item>CGM:  Computer Graphics Metafile</item>
<item>PICT:  Macintosh drawing format</item>
<item>TIFF:  Tagged Image File Format</item>
<item>GIF:  Graphics Interchange Format</item>
<item>PBM:  Portable Bit Map</item>
<item>PCX:  IBM PC raster format</item>
<item>BMP:   Microsoft bitmap format</item>
<item>JPEG:  Joint Photographic Expert Group</item>
<item>QuickTime:  Apple real-time image system</item>
<item>Photo-CD:  Kodak Photo Compact Disk format</item>
</list></p>

<p>Brief descriptions of all the above are given below.  Where possible,
current addresses or other contact information are shown for the
originator of each format.  Many formal standards, especially those
promulgated by ISO and many related national organizations (ANSI, DIN,
BSI, and many more), are available from those national organizations.
Addresses may be found in any standard organizational directory for the
country in question.

<!-- One such source is the American National Standards       -->
<!-- Institute (ANSI), 11 West 42nd Street, 13th floor, New   -->
<!-- York, NY 10036 USA, phone 212-642-4900, fax              -->
<!-- 212-348-0023.</p>                                        --></p>

<p>For each format, a sample notation declaration is given, using a
formal public identifier constructed from the best information available
at the date of publication.  It is recommended that such formal public
identifiers always be used in the interchange of documents between
sites.  Unless otherwise noted, however, these formal public identifiers
have been formulated by the TEI, and not by the owners of the
notation, as is indicated by the use of <mentioned>TEI</mentioned> as the
owner identifier.
If more recent versions of these formal public identifiers, or versions
promulgated by the owners of the notation, are available at the time of
document interchange, they should be used in preference to those shown
here.</p>

<p>Support for formal public identifiers varies somewhat among existing
SGML systems; for local processing, the notation declaration may
therefore need to include a system identifier in addition to the formal
public identifier.  The documentation for the SGML system in use should
be consulted for details.</p>

<div3><head>Vector Graphic Formats</head>

<list type="gloss">

<label>CGM:  Computer Graphics Metafile</label>

<item>This format is a popular representation for vector graphics
specified by an ISO standard, ISO 8632:1987, amended in 1990.
The standard defines binary, character, and plain-text encodings;
the non-binary forms are safer for blind interchange,
especially over networks.  Documentation on CGM is available from ISO
and from its member national bodies such as AFNOR, ANSI, BSI, DIN, JIS,
etc.  Sample declarations:

<eg>
<![ CDATA [
<!NOTATION cgm PUBLIC
    'ISO 8632:1987//NOTATION Computer Graphics Metafile//EN'>

<!NOTATION cgmchar  PUBLIC
    'ISO 8632-2:1987//NOTATION Character encoding//EN'>
<!NOTATION cgmbin   PUBLIC
    'ISO 8632-3:1987//NOTATION Binary encoding//EN'>
<!NOTATION cgmclear PUBLIC
    'ISO 8632-4:1987//NOTATION Clear text encoding//EN'>
]]>
</eg>
</item>

<label>PICT:  Macintosh drawing format</label>

<item>This format is universally supported on Macintosh(tm) systems, and
readable by a limited range of software for other systems.
Documentation is available from Apple Computer Company, Cupertino,
California USA.

<eg>
<![ CDATA [
<!NOTATION pict PUBLIC
    '-//TEI//NOTATION PICT:  Macintosh Drawing Format//EN'>
]]>
</eg>

</item>
</list>

</div3>

<div3><head>Raster Graphic Formats</head>

<list type="gloss">

<label>TIFF:  Tagged Image File Format</label>

<item>Currently the most widely supported raster image format,
especially for black and white images, TIFF is also one of the few
formats commonly supported on more than one operating system.  The
drawback to TIFF is that it actually is a wrapper for several formats,
and some TIFF-supporting software does not support all variants.  TIFF
files may use LZW, CCITT Group 4, or PackBits compression methods, or
may use no compression at all.  Also, TIFF files may be monochrome,
greyscale, or color.  All such options should be specified in prose at
the end of the <gi>encodingDesc</gi> section of the TEI header for any
document including TIFF images.  TIFF is owned by Aldus Corporation.
Documentation on TIFF is available from them at Craigcook Castle,
Craigcook Road, Edinburgh EH4 3UH, Scotland, or 411 First Avenue
South, Seattle, Washington 98104 USA.

<eg>
<![ CDATA [
<!NOTATION tiff PUBLIC
   '-//TEI//NOTATION Aldus Tagged Image File Format//EN'>
]]>
</eg></item>

<label>GIF:  Graphics Interchange Format</label>

<item>Color raster images are widely available in this form, which was
created by CompuServ Information Services, but has by now been
implemented for many other systems as well.  Documentation on GIF is
copyright by, and is available from, CompuServe Incorporated, Graphics
Technology Department, 5000 Arlington Center Boulevard, Columbus, Ohio
43220 USA.

<eg>
<![ CDATA [
<!NOTATION gif PUBLIC
  '-//TEI//NOTATION
  Compuserve Graphics Interchange Format//EN' >
]]>
</eg></item>


<label>PBM:  Portable Bit Map</label>

<item>PBM files are easy to process, eschewing all compression in favor
of transparency of file format.  PBM files can, of course, be compressed
by generic file-compression tools for storage and transfer.  Public
domain software exists which will convert many other formats to and from
PBM.  Documentation on PBM is copyright by Jeff Poskanzer, and is available
widely on the Internet.

<eg>
<![ CDATA [
<!NOTATION pbm PUBLIC
  '-//TEI//NOTATION Jeff Poskanzer, Portable Bit Map//EN' >
]]>
</eg>
</item>

<label>PCX:  IBM PC raster format</label>

<item>This format is used by most IBM PC paint programs, and supports
both monochrome and color images.  Documentation is available from
ZSoft Corporation, Technical Support Department, ATTN: Technical
Reference Manual, 450 Franklin Rd. Suite 100, Marietta, GA 30067 USA.

<eg>
<![ CDATA [
<!NOTATION pcx PUBLIC
  '-//TEI//NOTATION PCX:  ZSoft IBM PC Raster Graphics Format//EN' >
]]>
</eg>

</item>

<label>BMP:   Microsoft bitmap format</label>
<item>This format is the standard raster format for computer using
Microsoft Windows (tm) or Presentation Manager (tm).  Documentation
is available from Microsoft Corporation.

<eg>
<![ CDATA [
<!NOTATION bmp PUBLIC
  '-//TEI//NOTATION BMP:  Microsoft Bitmap Graphics Format//EN' >
]]>
</eg>

</item>

</list></div3>

<div3><head>Photographic and Motion Video Formats</head>

<list type="gloss">

<label>JPEG:  Joint Photographic Expert Group</label>

<item>This standard is sponsored by CCITT and by ISO.  It is ISO/IEC
Draft International Standard 10918-1, and CCITT T.81.  It handles
monochrome and color images with a variety of compression techniques.
JPEG per se, like CCITT Group IV, must be encapsulated before
transmission; this can be done via TIFF, or via the JPEG File
Interchange Format (JFIF).

<eg>
<![ CDATA [
<!NOTATION JPEG PUBLIC
  'ISO DIS 10918//NOTATION JPEG Graphics Format//EN' >
]]>
</eg>

</item>

<label>QuickTime:  Apple real-time image system</label>

<item>QuickTime is a proprietary method introduced by Apple Computer
Company to synchronize the display of various data.  The data can
include frames of video, sound, lighting control equipment, and other
things.  Viewers for QuickTime productions are available for Apple and
other computers.  Further information is available from Apple Computer
Incorporated, 10201 North de Anza Boulevard MS 23AQ, Cupertino,
California 95014 USA.

<eg>
<![ CDATA [
<!NOTATION QuickTime PUBLIC
  '-//TEI//NOTATION Apple QuickTime Video Data Format//EN' >
]]>
</eg>

</item>

<label>Photo-CD:  Kodak Photo Compact Disk format</label>

<item>This format was introduced by Kodak for rasterizing photographs
and storing them on CD-ROMs (about one hundred 35mm file images fit on
one disk), for display on televisions or CD-I systems.  Information on
Photo-CD is available from Kodak Limited, Research and Development,
Headstone Drive, Harrow, Middlesex HA1 4TY, UK.

<eg>
<![ CDATA [
<!NOTATION pcx PUBLIC
  '-//TEI//NOTATION
  Eastman Kodak Photo-CD Raster Graphics Format//EN' >
]]>
</eg>

</item>

</list>

<p>As noted above, the reader will encounter many, many other graphics
formats.  Other formats are not recommended for data interchange
according to the TEI scheme at this time, but may be included in a TEI
document without affecting its conformance in other respects, provided
that a notation declaration is provided.
</p></div3></div2>
<!-- delete remainder for now -->

<!-- <div3><head>Other (Non-Recommended) Formats</head> -->
<!-- <div4><head>Vector Graphic Formats</head> <list type=gloss> -->
<!-- <label>IGES: Initial Graphics Exchange Specification</label> -->
<!-- <item><p>This format was introduced by the American National -->
<!-- Bureau of Standards (NBS) and the American National -->
<!-- Standards Institute (ANSI); versions exists from 1980, 1983, -->
<!-- 1986, and 1987.  It is used for exchange of some engineering -->
<!-- and product data, and can include both vector and raster -->
<!-- representations.  ASCII and binary encodings are defined. -->
<!-- <p>IGES will likely be superseded by the STEP effort: -->
<!-- Standard for the Exchange of Product Data.  This effort -->
<!-- involves a wider range of international expertise, and is -->
<!-- being developed through ISO as ISO CD 10303.  The American -->
<!-- effort relating to STEP is called PDES: -->
<!--  Product Data Exchange using STEP.</item> </list> </div4> -->
<!-- <div4><head>Raster Graphic Formats</head> <list type=gloss> -->
<!-- <label>EPS: Encapsulated Postscript</label> <item>This is a -->
<!-- variant of Postscript, in which each page image program is -->
<!-- preceded by a bitmapped image that can be displayed via -->
<!-- software much simpler than a full Postscript -->
<!-- interpreter.</item> <label>CALS: US Department of Defense -->
<!-- CALS raster</label> <item><p>These files are compressed -->
<!-- using CCITT Group 4 compression (the same method used by fax -->
<!-- machines and some TIFF files.  However, a CALS-specific -->
<!-- header comes before the data, to specify resolution, -->
<!-- orientation, and other information.  <p>The header of a CALS -->
<!-- Group IV raster image is defined in US Department of Defense -->
<!-- standard MIL-M-28002.  The compression itself is defined in -->
<!-- CCITT standard T.30, found in Fascicle VII.3: Terminal -->
<!-- Equipment and Protocols for Telematic Services, published -->
<!-- 1989 in Geneva by the International Telecommunication -->
<!-- Union.  It derives from the work of the IXth Plenary -->
<!-- Assembly of the International Telegraph and Telephone -->
<!-- Consultative Committee, Melbourne, 14-25 November 1988. -->
<!--  ISBN 92-61-0361102.</item> <label>SunRaster: Sun -->
<!-- Microsystems(tm) format</label> <item>This is supported on -->
<!-- Sun and some other Unix systems.  There are monochrome and -->
<!-- color variants.  Sun Microsystems owns this formats, and can -->
<!-- be reached at:</item> <label>DCX:</label><item> A multi-page -->
<!-- version of PCX</item> <label>MacPaint: Macintosh simple -->
<!-- raster format <item>A bitmap-only subset of Macintosh PICT -->
<!-- format, seldom used.  </item> <label>MSPAINT:<item> -->
<!-- Microsoft paint <label>WPMETA: WordPerfect Metafile</label> -->
<!-- <item>A format used by the WordPerfect word-processing -->
<!-- system for raster images embedded within files.  Further -->
<!-- information is available from WordPerfect -->
<!-- Corporation,....</item> <label>XWD: X Window Dump -->
<!-- format</label> <item>A format used on X Windows systems, -->
<!-- mainly for storing snapshots of windows displayed on screen -->
<!-- (as for inclusion when writing software -->
<!-- documentation).</item> </list> </div4> <div4><head>Page -->
<!-- layout formats</head> <list type=gloss> <label>PostScript: -->
<!-- Adobe printer image format</label> <item>This is a -->
<!-- printer-control language supported by most current -->
<!-- high-resolution printers.  It is actually a programming -->
<!-- languages, and so can be used to represent either raster or -->
<!-- vector graphic images of pages, or anything else.  A -->
<!-- Postscript interpreter is required to interpret its programs -->
<!-- and produce a displayed image.  It is owned by Adobe Systems -->
<!-- Incorporated, and exists in two flavors: Level 1 as of 1985, -->
<!-- and Level 2 as of 1990.  See also EPS, below.</item> -->
<!-- <label>HPGL</label> <item>A printer control language -->
<!-- originated by Hewlett-Packard Corporation.  </item> </list> -->
<!-- </div4></div3> <div3><head>Other Formats</head> <p>The -->
<!-- reader may encounter a wide variety of other formats.  Some -->
<!-- are listed here, and none of these are currently recommended -->
<!-- by these Guidelines.  However, should an encoder find it -->
<!-- necessary to use such a format the name specified here must -->
<!-- be used as the notation name. -->
<!--  Countless other formats are used by particular companies or -->
<!-- programs; those are omitted as being, by definition, -->
<!-- unportable and inappropriate for data interchange.</p> -->
<!-- <p>Vector formats include: <list type=gloss> -->
<!-- <label>DDES2-IADD:<item>Digital Data Exchange -->
<!-- Specification-International Association of -->
<!-- Diecutting-Diemaking.  ANSI IT8.6-1991, used primarily in -->
<!-- North America for exchanging box-manufacturing data. -->
<!-- <label>CFF2<item>Common File Format: A European format for -->
<!-- vector image and text interchange, based on DDES-IADD. -->
<!-- <label>DXF<item>Drawing Interchange Format: Owned and used -->
<!-- by AutoDesk Incorporated (a maker of engineering software), -->
<!-- 2320 Marinship Way, Sausalito, California 94965 USA. -->
<!-- <label>GKS<item>Graphical Kernel System.  ISO standard 7942 -->
<!-- (1985), with amendments pending.  Essentially a programming -->
<!-- library to support displaying two-dimensional graphics; -->
<!-- supported on a variety of workstations. -->
<!-- <label>GKS-3D<item>Graphical Kernel System extension for -->
<!-- 3-dimensions.  ISO standard 8805 (1988).  Can operate on -->
<!-- 2-dimensional GKS constructs transparently. -->
<!-- <label>PHIGS<item>Programmers Hierarchical Interactive -->
<!-- Graphics System: ISO standard 9592 (1990).  Essentially a -->
<!-- programming library to support interactive graphics. -->
<!-- PHIGS-PLUS is an extended variant.  <label>SET<item>Standard -->
<!-- dEchange et de Transfert: Sponsored by Association Francaise -->
<!-- De Normalisation (AFNOR), Tour Europe, Cedex 7, F-92049 -->
<!-- Paris la Defense, France.  <label>VDAFS<item>VDA Surface -->
<!-- Interface: Versions 1.0 (1986) sponsored by DIN (Germany); -->
<!-- extensions under consideration.  <label> Renderman<item>A -->
<!-- format used by Pixar Corporation) </list> <p>Raster formats -->
<!-- include: <list type=gloss> <label>DES<item>Digital Data -->
<!-- Exchange Specifications: For use with magnetic tapes. -->
<!-- Sponsored by ANSI IT8.1.  <label>IPI-OOF<item>Image -->
<!-- Processing and Interchange: Image Interchange Facility.  ISO -->
<!-- draft standard 12087; this format has apparently not yet -->
<!-- been implemented.  <label>JBIG<item>Joint Bilevel Image -->
<!-- Group: ISO draft standard 11544, and CCITT T.82.  Usage -->
<!-- unknown.  <label>ACR-NEMA <item> Used for exchanging -->
<!-- uncompressed medical raster images such as CT, MR, -->
<!-- ultrasound, and PET images.  Provides for extensive -->
<!-- cataloging information associated with images.  Available as -->
<!-- ACR-NEMA Standards Publication No 300-1988 from National -->
<!-- Electrical Manufacturers Association, 2101 L Street, N.W., -->
<!-- Washington, DC 20037 USA <label>FITS<item>Flexible Image -->
<!-- Transfer System: A NASA standard (NSDSSO 100-0.1) for -->
<!-- exchanging astronomical images.  Available from NASA Science -->
<!-- Data Systems Standards Office, Code 933, NASA Goddard Space -->
<!-- Flight Center, Greenbelt, MD 20771 USA <label>TARGA <item> -->
<!-- Apparently a binary image encapsulation format used by AT -->
<!-- &amp;T.  Information available from Truevision Customer -->
<!-- Service at (317) 576-8118, or AT&amp;T Electronic -->
<!-- Photography and Imaging Center, 2002 Wellesley Ave., -->
<!-- Indianapolis, IN 42619 USA.  </list> </div3> -->
<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-default-dtd-file:"~/lib/psgml/p2odd.ced"
sgml-parent-document:(quote ("/home/tei/P3/Master/Odds/p2.odd" "tei.1" "text" "body" "div1" "div2"))
sgml-omittag:t
sgml-shorttag:t
End:
-->


</div1>


<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-default-dtd-file:"~/lib/psgml/p2odd.ced"
sgml-parent-document:("/home/tei/P3/Master/Odds/p2.odd" "TEI.1" "TEXT" "BODY" "DIV1")
sgml-omittag:t
sgml-shorttag:t
End:
-->
             <!-- 22 Formulae and Tables -->
<!-- Revisions:                                               -->
<!-- 26 mar: LB: read thro: title change -->
<!-- 28 feb: fixed typos noted by DTL -->
<!-- 93-06-03 : MSM : change entity names for parts           -->
<!-- 31 may: LB: added credit for stig -->
<!-- 93-03-11 : MSM : last minute changes as per LB           -->
<!-- 93-03-10 : MSM : revise:  add refs to CB, DS, recast     -->
<!-- 93-03-08 : MSM : embed entity refs here, not in driver   -->
<!--                                                          -->
<!-- Date: Sat, 06 Mar 1993 21:59:42 +0000                    -->
<!-- From: Lou Burnard < lou@vax.ox.ac.uk >                   -->
<!-- To: U35395@UICVM.UIC.EDU                                 -->
<!-- CC: lou@vax.ox.ac.uk                                     -->
<!-- Subject: CC.odd (2 of 10)                                -->

<!-- 1 mar 93  split out into CC/CB -->
<!-- 26 Nov 92 : LB started draft  -->

<div1 id=CC n=23><head>Language Corpora</head>

<p>The term <term>language corpus</term> is used to mean a number of
rather different things.  It may refer simply to any collection of
linguistic data (written, spoken, or a mixture of the two), although
many practitioners prefer to reserve it for collections which have
been organized or collected with a particular end in view, generally to
characterize a particular state or variety of one or more languages.
Because opinions as to the best method of achieving this goal differ,
various subcategories of corpora have also been identified.  For our
purposes however, the distinguishing characteristic of a corpus is that
its components have been selected or structured according to some
conscious set of design criteria.

<p>These design criteria may be very simple and undemanding, or very
sophisticated.  A corpus may be intended to represent (in the
statistical sense) a particular linguistic variety or sublanguage, or it
may be intended to represent all aspects of some assumed
<socalled>core</socalled> language.  A corpus may be made up
of whole texts or of fragments or text samples.  It may be a
<soCalled>closed</soCalled> corpus, or an <soCalled>open</soCalled> or
<soCalled>monitor</soCalled> corpus, the composition of which may change
over time.  However, since an open corpus is of necessity finite at any
particular point in time, the only likely effect of its expansibility
from the encoding point of view may be some increased difficulty in
maintaining consistent encoding practices (see further section <ptr
target=CCrec>). For simplicity, therefore, our discussion largely
concerns ways of encoding closed corpora, regarded as single but
composite texts.

<!-- Change intro to next para, modify definition of unitary  -->
<!-- text (SMALLEST whole).  -MSM                             -->

<p>Language corpora are regarded by these Guidelines as
<term>composite texts</term> rather than <term>unitary texts</term>
(on this distinction, see chapter <ptr target=DS>).
This is because although
each discrete sample of language in a corpus clearly has a claim to be
considered as a text in its own right, it is also regarded as a
subdivision of some larger object, if only for convenience of analysis.
Corpora share a number of characteristics with other types of composite
texts, including anthologies and collections.  Most notably, different
components of composite texts may exhibit different structural
properties (for example, some may be composed of verse, and others of
prose), thus potentially requiring elements from different TEI bases.
Composite texts are thus especially likely to require the techniques for
combining base tag sets described in section <ptr target=STco>.

<p>Aside from these high-level structural differences, and possibly
differences of scale, the encoding of language corpora and the encoding
of individual texts present identical sets of problems.  Any of the
encoding techniques and elements presented in other chapters of these
Guidelines may therefore prove relevant to some aspect of corpus
encoding and may be used in corpora.  However, we do not repeat here the
discusssion of such fundamental matters as the representation of
multiple character sets (see chapter <ptr target=CH>); nor attempt to
summarize the variety of elements provided for encoding basic structural
features such as quoted or highlighted phrases, cross references, lists,
notes, editorial changes and reference systems (see chapter <ptr
target=CO>).  In addition to these general purpose elements, these
Guidelines offer a range of more specialized sets of tags which may be
of use in certain specialized corpora, for example those consisting
primarily of verse (chapter <ptr target=VE>), drama (chapter <ptr
target=DR>), transcriptions of spoken text (chapter <ptr target=TS>),
<!-- letters and memoranda (chapter <ptr target=LM>)-->
etc.  Chapter <ptr target=ST> should be reviewed for details of how
these and other components of the Guidelines should be tailored to
create a document type definition appropriate to a given application.
In sum, it should not be asssumed that only the matters specifically
addressed in this chapter are of importance for corpus creators.

<p>This chapter does however include some other material
relevant to corpora and corpus-building, for which no other location
appeared suitable.  It begins with a review of the distinction between
unitary and composite texts, and of the different methods provided by
these Guidelines for representing composite texts of different kinds
(section <ptr target=CCDef>).  Section <ptr target=CCah> describes a
set of additional header elements provided for the documentation of
contextual information, of importance largely though not exclusively to
language corpora.  This is the additional tag set for language corpora
proper.  Section <ptr target=CCas> discusses a mechanism by which
individual parts of the TEI Header may be associated with different
parts of a TEI-conformant text.  Section <ptr target=CCan> reviews
various methods of providing linguistic annotation in corpora, with some
specific examples of relevance to current practice in corpus
linguistics.  Finally, section <ptr target=CCrec> provides some general
recommendations about the use of these Guidelines in the building of
large corpora.

<!-- <note place=foot>Parts of this chapter are derived from -->
<!-- working papers of the Work Group on Corpora, chaired by -->
<!-- Douglas Biber, the Work Group on Linguistic Description, -->
<!-- chaired by D. Terence Langendoen, and the Work Group on -->
<!-- Spoken Texts, chaired by Stig Johansson.  The membership of -->
<!-- these work groups is listed in the preface.</note> -->

