<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Draft//EN">
<HTML>
<HEAD>
<TITLE>The Languages of Thot</TITLE>
</HEAD>
<BODY>
<DIV class="frontmatter" align=center>
<H1>The Languages of Thot</H1>
<H3>Vincent Quint</H3>
<H4>translated from French by Ethan Munson</H4>
<H4>Version of December 14, 1996</H4>
<HR>
</DIV>
<DIV class="chapter">
<H1>The document model of Thot</H1>
<P>
All of the services which Thot provides to the user are based on the system's
internal document representation. This representation is itself derived from
the document model which underlies Thot. The model is presented here, prior
to the description of the languages which permit the generic specification of
documents.</P>
<DIV class="section">
<H2>The logical structure of documents</H2>
<P>
The document model of Thot is primarily designed to allow the user to operate
on those entities which he has in mind when he works on a document. The model
makes no assumptions about the nature of these entities. It is essentially
these logical entities, such as paragraphs, sections, chapters, notes, titles,
and cross-references which give a document its logical structure.</P>
<P>
Because of this model, the author can divide his document into chapters,
giving each one a title. The content of these chapters can be further divided
into sections, subsections, etc. The text is organized into successive
paragraphs, according to the content. In the writing phase, the lines, pages,
margins, spacing, fonts, and character styles are not very important. In fact,
if the system requires documents to be written in these terms, it gets in the
way. So, Thot's model is primarily based on the logical aspect of documents.
The creation of a model of this type essentially requires the definition :</P>
<UL>
<LI>of the entities which can appear in the documents,
<LI>and the relations between these entities.
</UL>
<P>
The choice of entities to include in the model can be subtle. Some documents
require chapters, while others only need various levels of sections. Certain
documents contain appendices, others don't. In different documents the same
logical entity may go by different names (e.g. ``Conclusion'' and
``Summary''). Certain entities which are absolutely necessary in some
documents, such as clauses in a contract or the address of the recipient in a
letter, are useless in most other cases.</P>
<P>
The differences between documents result from more than just the entities that
appear in them, but also from the relationships between these entities and the
ways that they are linked. In certain documents, notes are spread throughout
the document, for example at the bottom of the page containing the
cross-reference to them, while in other documents they are collected at the
end of each chapter or even at the end of the work. As another example, the
introduction of some documents can contain many sections, while in other
documents, the introduction is restricted to be a short sequence of
paragraphs.</P>
<P>
All of this makes it unlikely that a single model can describe any document at
a relatively high level. It is obviously tempting to make up a list of widely
used entities, such as chapters, sections, paragraphs, and titles, and then
map all other entities onto the available choices. In this way, an
introduction can be supported as a chapter and a contract clause supported as
a paragraph or section. However, in trying to widen the range of usage of
certain entities, their meaning can be lost and the power of the model
reduced. In addition, while this widening partially solves the problem of
choosing entities, it does not solve the problem of their organization: when a
chapter must be composed of sections, how does one indicate that an
introduction has none when it is merely another chapter? One solution is to
include introductions in the list of supported entities. But then, how does
one distinguish those introductions which are allowed to have sections from
those which are not. Perhaps this could be done by defining two types of
introduction. Clearly, this approach risks an infinite expansion of the list
of widely used entities.</P>
</DIV>
<DIV class="section">
<H2>Generic and specific structures</H2>
<P>
Thus, it is apparently impossible to construct an exhaustive inventory of all
those entities which are necessary and sufficient to precisely describe any
document. It also seems impossible to specify all possible arrangements of
these entities in a document. This is why Thot uses a <EM>meta-model</EM>
instead, which permits the description of numerous <EM>models</EM>, each one
describing a <EM>class</EM> of documents.</P>
<P>
A <EM>class</EM> is a set of documents having very similar structure. Thus,
the collection of research reports published by a laboratory constitutes a
class; the set of commercial proposals by the sales department of a company
constitutes another class; the set of articles published by a journal
constitutes a third class. Clearly, it is not possible to enumerate every
possible document class. It is also clear that new document classes must be
created to satisfy new needs and applications.</P>
<P>
To give a more rigorous definition of classes, we must introduce the ideas of
<EM>generic structure</EM> and <EM>specific structure</EM>. Each document has
a <EM>specific structure</EM> which organizes the various parts which comprise
it. We illustrate this with the help of a simple example comparing two
reports, A and B (<A href="#specstruct">see Figure</A>). The report A contains
an introduction followed by three chapters and a conclusion. The first
chapter contains two sections, the second, three sections. That is the
<EM>specific</EM> structure of document A. Similarly, the structure of
document B is: an introduction, two chapters, a conclusion; Chapter 1 has
three sections while Chapter 2 has four. The specific structures of these two
documents are thus different.</P>
<DIV class="figure">
<HR>
<PRE>
Report A Report B
Introduction Introduction
Chapter 1 Chapter 1
Section 1.1 Section 1.1
Section 1.2 Section 1.2
Chapter 2 Section 1.3
Section 2.1 Chapter 2
Section 2.2 Section 2.1
Section 2.3 Section 2.2
Chapter 3 Section 2.3
Conclusion Section 2.4
Conclusion
</PRE>
<P align=center>
<EM><A name="specstruct">Two specific structures</A></EM></P>
<HR>
</DIV>
<P>
The <EM>generic structure</EM> defines the ways in which specific structures
can be constructed. It specifies how to generate specific structures. The
reports A and B, though different, are constructed in accordance with the same
generic structure, which specifies that a report contains an introduction
followed by a variable number of chapters and a conclusion, with each chapter
containing a variable number of sections.</P>
<P>
There is a one-to-one correspondence between a class and a generic structure:
all the documents of a class are constructed in accordance with the same
generic structure. Hence the definition of the class: a class is a set of
documents whose specific structure is constructed in accordance with the same
generic structure. A class is characterized by its generic structure.</P>
<P>
Thus, a generic structure can be considered to be a model at the level which
interests us, but only for one class of documents. When the definition is
limited to a single class of documents, it is possible to define a model which
does a good job of representing the documents of the class, including the
necessary entities and unencumbered by useless entities. The description of
the organization of the documents in the class can then be sufficiently
precise.</P>
</DIV>
<DIV class="section">
<H2>Logical structure and physical structure</H2>
<P>
Generic structures only describe the <EM>logical</EM> organization of
documents, not their <EM>physical</EM> presentation on a screen or on sheets
of paper. However, for a document to be displayed or printed, its graphic
presentation must be taken into account.</P>
<P>
An examination of current printed documents shows that the details of
presentation essentially serve to bring out their logical structure. Outside
of some particular domains, notably advertising, the presentation is rarely
independent of the logical organization of the text. Moreover, the art of
typography consists of enhancing the organization of the text being set,
without catching the eye of the reader with overly pronounced effects. Thus,
italic and boldface type are used to emphasize words or expressions which have
greater significance than the rest of the text: keywords, new ideas,
citations, book titles, etc. Other effects highlight the organization of the
text: vertical space, margin changes, page breaks, centering, eventually
combined with the changes in the shapes or weight of the characters. These
effects serve to indicate the transitions between paragraphs, sections, or
chapters: an object's level in the logical structure of the document is shown
by the markedness of the effects.</P>
<P>
Since the model permits the description of all of the logical structure of the
document, the presentation can be derived from the model without being
submerged in the document itself. It suffices to use the logical structure of
the document to make the desired changes in its presentation: changes in type
size, type style, spacing, margin, centering, etc.</P>
<P>
Just as one cannot define a unique generic logical structure for all document
classes, one cannot define universal presentation rules which can be applied
to all document classes. For certain types of documents the chapter titles
will be centered on the page and printed in large, bold type. For other
documents, the same chapter titles will be printed in small, italic type and
aligned on the left margin.</P>
<P>
Therefore, it is necessary to base the presentation specifications for
documents on their class. Such a specification can be very fine-grained,
because the presentation is expressed in terms of the entities defined in the
generic logical structure of the class. Thus, it is possible to specify a
different presentation for the chapter titles and the section titles, and
similarly to specify titles for the sections according to their level in the
section hierarchy. The set of rules which specify the presentation of all the
elements defined in a generic logical structure is called a <EM>generic
presentation</EM>.</P>
<P>
There are several advantages derived from having a presentation linked to the
generic structure and described by a generic presentation. Homogeneity is the
first. Since every document in a class corresponds to the same generic
logical structure, a homogenous presentation for different documents of the
same class can be assured by applying the same generic presentation to all
documents of the class. Homogeneity of presentation can also be found among
the entities of a single document: every section heading will be presented in
the same way, the first line of every paragraph of the same type will have the
same indentation, etc.</P>
<P>
Another advantage of this approach to presentation is that it facilitates
changes to the graphical aspect of documents. A change to the generic
presentation rules attached to each type of entity will alter the presentation
of the entire document, and will do so homogenously. In this case, the
internal homogeneity of the class is no longer assured, but the way to control
it is simple. It suffices to adopt a single generic presentation for the
entire class.</P>
<P>
If the presentation of the class does not have to be homogenous, then the
appearance of the document can be adapted to the way it will be used or to the
device used to render it. This quality is sufficient to allow the existence
of <A name="mulpres">many generic presentations</A> for the same document
class. By applying one or the other of these presentations to it, the document
can be seen under different graphical aspects. It must be emphasized that
this type of modification of the presentation is not a change to the document
itself (in its specific logical structure or its content), but only in its
appearance at the time of editing or printing.</P>
</DIV>
<DIV class="section">
<H2>Document structures and object structures</H2>
<P>
So far, we have only discussed the global structure of documents and have not
considered the contents found in that structure. We could limit ourselves to
purely textual contents by assuming that a title or a paragraph contains a
simple linear text. But this model would be too restrictive. In fact,
certain documents contain not only text, but also contain tables, diagrams,
photographs, mathematical formulas, and program fragments. The model must
permit the representation of such <EM>objects</EM>.</P>
<P>
Just as with the whole of the document, the model takes into account the
logical structure of objects of this type. Some are clearly structured,
others are less so. Logical structure can be recognized in mathematical
formulas, in tables, and in certain types of diagrams. On the other hand, it
is difficult to define the structure of a photograph or of some drawings. But
in any case, it does not seem possible to define one unique structure which
can represent every one of these types of objects. The approach taken in the
definition of meta-structure and document classes also applies to objects.
Object classes can be defined which put together objects of similar type,
constructed from the same generic logical structure.</P>
<P>
Thus, a mathematical class can be defined and have a generic logical structure
associated with it. But even if a single generic structure can represent a
sufficient variety of mathematical formulas, for other objects with less
rigorous structure, multiple classes must be defined. As for documents, using
multiple classes assures that the model can describe the full range of objects
to be presented. It also permits the system to support objects which were not
initially anticipated. Moreover, this comment applies equally to mathematics:
different classes of formulas can be described depending on the domain of
mathematics being described.</P>
<P>
Since objects have the same level of logical representation as documents, they
gain the same advantages. In particular, it is possible to define the
presentation separately from the objects themselves and attach it to the
class. Thus, as for documents, objects of the same type have a uniform
presentation and the presentation of every object in a given class can be
changed simply by changing the generic presentation of the class. Another
advantage of using this document model is that the system does not bother the
user with the details of presentation, but rather allows the user to
concentrate on the logical aspect of the document and the objects.</P>
<P>
It is clear that the documents in a class do not necessarily use the same
classes of objects: one technical report will contain tables while another
report will have no tables but will use mathematical formulas. The usable
object classes are not always mentioned in a limiting way in the generic
logical structure of documents. Rather, they can be chosen freely from a
large set, independent of the document class.</P>
<P>
Thus, the object classes will be made commonplace and usable in every
document. The notion of ``object'' can be enlarged to include not only
non-textual elements, but also certain types of textual elements which can
appear in practically every document, whatever their class. Among these
textual elements, one can mention enumerations, descriptions, examples,
quotations, even paragraphs.</P>
<P>
Thus, the document model is not a single, general model describing every type
of document in one place. Rather, it is a meta-model which can be used to
describe many different models each of which represents either a class of
similar documents or a class of similar objects which every document can
include.</P>
</DIV>
<HR>
</DIV>
<DIV class="chapter">
<H1>The S language</H1>
<DIV class="section">
<H2>Document meta-structure</H2>
<P>
Since the concept of meta-structure is well suited to the task of describing
documents at a high level of abstraction, this meta-structure must be
precisely defined. Toward that end this section first presents the basic
elements from which documents and structured objects are composed and then
specifies the ways in which these basic elements are assembled into structures
representing complete documents and objects.</P>
<DIV class="subsection">
<H3>The basic types</H3>
<P>
At the lowest level of a document's structure, the first atom considered is
the character. However, since characters are seldom isolated, usually
appearing as part of a linear sequence, and in order to reduce the complexity
of the document structure, <EM>character strings</EM> are used as atoms and
consecutive characters belonging to the same structural element are grouped in
the same character string.</P>
<P>
If the structure of a document is not refined to go down to the level of
words or phrases, the contents of a simple paragraph can be considered to be a
single character string. On the other hand, the title of a chapter, the title
of the first section of that chapter, and the text of the first paragraph of
that section constitute three different character strings, because they belong
to distinct structural elements.</P>
<P>
If, instead, a very fine-grained representation for the structure of a
document is sought, character strings could be defined to contain only a
single word, or even just a single character. This is the case, for example,
in programs, for which one wants to retain a structure very close to the
syntax of the programming language. In this case, an assignment statement
initializing a simple variable to zero would be composed of two structural
elements, the identifier of the variable (a short character string) and the
assigned value (a string of a single character, `0').</P>
<P>
The character string is not the only atom necessary for representing those
documents that interest us. It suffices for purely textual documents, but as
soon as the non-textual objects which we have considered arise, there must be
other atoms; the number of objects which are to be represented determines the
number of types of atoms that are necessary.</P>
<P>
Primitive <EM>graphical elements</EM> are used for tables and figures of
different types. These elements are simple geometric shapes like horizontal
or vertical lines, which are sufficient for tables, or even oblique lines,
arrows, rectangles, circles, polygons, and curves for use in figures. From
these elements and character strings, graphical objects and tables can be
constructed.</P>
<P>
Photographs, though having very little structure, must still appear in
documents. They are supported by <EM>picture</EM> elements, which are
represented as matrices of pixels.</P>
<P>
Finally, mathematical notations require certain elements which are
simultaneously characters and graphical elements, the <EM>symbols</EM>. By way
of example, radicals, integration signs, or even large parentheses are
examples of this type of atom. The size of each of these symbols is
determined by its environment, that is to say, by the expression to which it
is attached.</P>
<P>
To summarize, the primitive elements which are used in the construction of
documents and structured objects are:</P>
<UL>
<LI>character strings,
<LI>graphical elements,
<LI>pictures,
<LI>and mathematical symbols.
</UL>
</DIV>
<DIV class="subsection">
<H3>Constructed elements</H3>
<P>
A document is evidently formed from primitive elements. But the model of Thot
also proposes higher level elements. Thus, in a document composed of several
chapters, each chapter is an element, and in the chapters each section is also
an element, and so on. A document is thus an organized set of elements.</P>
<P>
In a document there are different sorts of elements. Each element has a
<EM>type</EM> which indicates the role of the element within the document as a
whole. Thus, we have, for example, the chapter and section types. The
document is made up of typed elements: elements of the type chapter and
elements of the type section, among others, but also character string elements
and graphical elements: the primitive elements are typed elements just as
well. At the other extreme, the document itself is also considered to be a
typed element.</P>
<P>
The important difference between the primitive elements and the other elements
of the document is that the primitive elements are atoms (they cannot be
decomposed), whereas the others, called <EM>constructed elements</EM>, are
composed of other elements, which can either be primitive elements or
constructed elements. A constructed element of type chapter (or more simply,
``a chapter'') is composed of sections, which are also constructed elements. A
paragraph, a constructed element, can be made up of character strings, which
are primitive elements, and of equations, which are constructed elements.</P>
<P>
A document is also a constructed element. This is an important point. In
particular, it allows a document to be treated as part of another document,
and conversely, permits a part of a document to be treated as a complete
document. Thus, an article presented in a journal is treated by its author as
a document in itself, while the editor of the journal considers it to be part
of an issue. A table or a figure appearing in a document can be extracted and
treated as a complete document, for example to prepare transparencies for a
conference.</P>
<P>
These thoughts about types and constructed elements apply just as well to
objects as they do to documents. A table is a constructed element made up of
other constructed elements, rows and columns. A row is formed of cells, which
are also constructed elements which contain primitive elements (character
strings) and/or constructed elements like equations.</P>
</DIV>
<DIV class="subsection">
<H3>Logical structure constructors</H3>
<P>
Having defined the primitive elements and the constructed elements, it is now
time to define the types of organization which allow the building of
structures. For this, we rely on the notion of the <EM>constructor</EM>. A
constructor defines a way of assembling certain elements in a structure. It
resides at the level of the meta-structure: it does not describe the existing
relations in a given structure, but rather defines how elements are assembled
to build a structure that conforms to a model.</P>
<P>
In defining the overall organization of documents, the first two constructors
considered are the aggregate and the list.</P>
<DIV class="subsubsection">
<H4>Aggregate and List</H4>
<P>
The <EM>aggregate</EM> constructor is used to define constructed element types
which are collections of a given number of other elements. These collections
may or may not be ordered. The elements may be either constructed or
primitive and are specified by their type. A report (that is, a constructed
element of the report type) has an aggregate structure. It is formed from a
title, an author's name, an introduction, a body, and a conclusion, making it
a collection of five element types. This type of constructor is found in
practically every document, and generally at several levels in a document.</P>
<P>
The <EM>list</EM> constructor is used to define constructed elements which are
ordered sequences of elements (constructed or primitive) having the same type.
The minimum and maximum numbers of elements for the sequence can be specified
in the list constructor or the number of elements can be left unconstrained.
The body of a report is a list of chapters and is typically required to
contain a minimum of two chapters (is a chapter useful if it is the only one
in the report?) The chapter itself can contain a list of sections, each
section containing a list of paragraphs. In the same way as the aggregate,
the list is a very frequently used constructor in every type of document.
However, these two constructors are not sufficient to describe every document
structure; thus other constructors supplement them.</P>
</DIV>
<DIV class="subsubsection">
<H4><A name="schemasandunits">Choice, Schema, and Unit</A></H4>
<P>
The <EM>choice</EM> constructor is used to define the structure of an element
type for which one alternative is chosen from several possibilities. Thus, a
paragraph can be either a simple text paragraph, or an enumeration, or a
citation.</P>
<P>
The choice constructor indicates the complete list of possible options, which
can be too restrictive in certain cases, the paragraph being one such case.
Two constructors, <EM>unit</EM> and <EM>schema</EM>, address this
inconvenience. They allow more freedom in the choice of an element type. If
a paragraph is defined by a schema constructor, it is possible to put in the
place of a paragraph a table, an equation, a drawing or any other object
defined by another generic logical structure. It is also possible to define a
paragraph as a sequence of units, which could be character strings, symbols,
or pictures. The choice constructor alone defines a generic logical structure
that is relatively constrained; in contrast, using units and schemas, a very
open structure can be defined.</P>
<P>
The <EM>schema</EM> constructor represents an object defined by a generic
logical structure chosen freely from among those available.</P>
<P>
The <EM>unit</EM> constructor represents an element whose type can be either a
primitive type or an element type defined as a unit in the generic logical
structure of the document, or in another generic logical structure used in the
document. Such an element may be used in document objects constructed
according to other generic structures.</P>
<P>
Thus, for example, if a cross-reference to a footnote is defined in the
generic logical structure ``Article'' as a unit, a table (an object defined by
another generic structure) can contain cross-references to footnotes, when
they appear in an article. In another type of document, a table defined by
the same generic structure can contain other types of elements, depending on
the type of document into which the table is inserted. All that is needed is
to declare, in the generic structure for tables, that the contents of cells
are units. In this way, the generic structure of objects is divided up
between different types of documents which are able to adapt themselves to the
environment into which they are inserted.</P>
</DIV>
<DIV class="subsubsection">
<H4>Reference and Inclusion</H4>
<P>
The <EM>reference</EM> is the last constructor. It is used to define document
elements that are cross-references to other elements, such as a section, a
chapter, a bibliographic citation, or a figure. The reference is
bi-directional. It can be used to access both the element being
cross-referenced and each of the elements which make use of the
cross-reference.</P>
<P>
References can be either <EM>internal</EM> or <EM>external</EM>. That is,
they can designate elements which appear in the same document or in another
document.</P>
<P>
The <EM><A name="inclusion">inclusion</A></EM> constructor is a special type
of reference. Like the reference, it is an internal or external bidirectional
link, but it is not a cross-reference. This link represents the ``live''
inclusion of the designated element; it accesses the most recent version of
that element and not a ``dead'' copy, fixed in the state in which it was found
at the moment the copy was made. As soon as an element is modified, all of
its inclusions are automatically brought up to date. It must be noted that,
in addition to inclusion, Thot permits the creation of ``dead'' copies.</P>
<P>
There are three types of inclusions: inclusions with full expansion,
inclusions with partial expansion, and inclusions without expansion. During
editing, inclusions without expansion are represented on the screen by the
name of the included document, in a special color, while inclusions with
expansion (full or partial) are represented by a copy (full or partial) of the
included element (also in a special color). The on-screen representation of a
partial inclusion is a <A href="#skeleton">``skeleton''</A> image of the
included document.</P>
<P>
Inclusion with complete expansion can be used to include parts of the same
document or of other documents. Thus, it can be either an internal or an
external link. It can be used to include certain bibliographic entries of a
scientific article in another article, or to copy part of a mathematical
formula into another formula of the same document, thus assuring that both
copies will remain synchronized.</P>
<P>
Inclusion without expansion or with partial expansion is used to include
complete documents. It is always an external link. It is used primarily to
divide very large documents into sub-documents that are easier to manipulate,
especially when there are many authors. So, a book can include some chapters,
where each chapter is a different document which can be edited separately.
When viewing the book on the screen, it might be desirable to see only the
titles of the chapters and sections. This can be achieved using inclusion
with partial expansion.</P>
<P>
During printing, inclusions without expansion or with partial expansion can be
represented either as they were shown on the screen or by a complete (and
up-to-date) copy of the included element or document.</P>
<P>
The inclusion constructor, whatever its type, respects the generic structure:
only those elements authorized by the generic structure can be included at a
given position in a document.</P>
</DIV>
<DIV class="subsubsection">
<H4>Mark pairs</H4>
<P>
It is often useful to delimit certain parts of a document independently from
the logical structure. For example, one might wish to attach some information
(in the form of an <A href="#attributes">attribute</A>) or a particular
treatment to a group of words or a set of consecutive paragraphs. <EM>Mark
pairs</EM> are used to do this.</P>
<P>
Mark pairs are elements which are always paired and are terminals in the
logical structure of the document. Their position in the structure of the
document is defined in the generic structure. It is important to note that
when the terminals of a mark pair are <EM>extensions</EM> (see the next
section), they can be used quite freely.</P>
</DIV>
<DIV class="subsubsection">
<H4><A name="restrictionextensions">Restrictions and Extensions</A></H4>
<P>
The primitive types and the constructors presented so far permit the
definition of the logical structure of documents and objects in a rigorous
way. But this definition can be very cumbersome in certain cases, notably
when trying to constrain or extend the authorized element types in a
particular context. <EM>Restrictions</EM> and <EM>extensions</EM> are used to
cope with these cases.</P>
<P>
A restriction associates with a particular element type <EM>A</EM>, a list of
those element types which elements of type <EM>A</EM> may not contain, even if
the definition of type <EM>A</EM> and those of its components authorize them
otherwise. This simplifies the writing of generic logical structures and
allows limitations to be placed, when necessary, on the choices offered by the
schema and unit constructors.</P>
<P>
Extensions are the inverse of restrictions. They identify a list of element
types whose presence <EM>is</EM> permitted, even if its definition and those
of its components do not authorize them otherwise.</P>
</DIV>
<DIV class="subsubsection">
<H4>Summary</H4>
<P>
Thus, four constructors are used to construct a document:</P>
<UL>
<LI>the aggregate constructor (ordered or not),
<LI>the list constructor,
<LI>the choice constructor and its extensions, the unit and schema
constructors,
<LI>the reference constructor and its variant, the inclusion.
</UL>
<P>
These constructors are also sufficient for objects. Thus, these constructors
provide a homogenous meta-model which can describe both the organization of
the document as a whole and that of the various types of objects which it
contains. After presenting the description language for generic structures,
we will present several examples which illustrate the appropriateness of the
model.</P>
<P>
The first three constructors (aggregate, list and choice) lead to tree-like
structures for documents and objects, the objects being simply the subtrees of
the tree of a document (or even of other objects' subtrees). The reference
constructor introduces other, non-hierarchical, relations which augment those
of the tree: when a paragraph makes reference to a chapter or a section, that
relation leaves the purely tree-like structure. Moreover, external reference
and inclusion constructors permit the establishment of links between different
documents, thus creating a hypertext structure.</P>
</DIV>
</DIV>
<DIV class="subsection">
<H3><A name="assocelem">Associated Elements</A></H3>
<P>
Thanks to the list, aggregate and choice constructors, the organization of the
document is specified rigorously, using constructed and primitive elements.
But a document is made up of more than just its elements; it clearly also
contains links between them. There exist elements whose position in the
document's structure is not determinable. This is notably the case for
figures and notes. A figure can be designated at many points in the same
document and its place in the physical document can vary over the life of the
document without any effect on the meaning or clarity of the document. At one
time, it can be placed at the end of the document along with all other
figures. At another time, it can appear at the top of the page which follows
the first mention of the figure. The figures can be dispersed throughout the
document or can be grouped together. The situation is similar for notes,
which can be printed at the bottom of the page on which they are mentioned or
assembled together at the end of the chapter or even the end of the work. Of
course, this brings up questions of the physical position of elements in
documents that are broken into pages, but this reflects the structural
instability of these elements. They cannot be treated the same way as
elements like paragraphs or sections, whose position in the structure is
directly linked to the semantics of the document.</P>
<P>
Those elements whose position in the structure of the document is not fixed,
even though they are definitely part of the document, are called
<EM>associated elements</EM>. Associated elements are themselves structures,
which is to say that their content can be organized logically by the
constructors from primitive and constructed elements.</P>
<P>
It can happen that the associated elements are totally disconnected from the
structure of the document, as in a commentary or appraisal of the entire work.
But more often, the associated elements are linked to the content of the
document by references. This is generally the case for notes and figures,
among others.</P>
<P>
Thus, associated elements introduce a new use for the reference constructor.
It not only serves to create links between elements of the principal structure
of the document, but also serves to link the associated elements to the
primary structure.</P>
</DIV>
<DIV class="subsection">
<H3><A name="attributes">Attributes</A></H3>
<P>
There remain logical aspects of documents that are not entirely described by
the structure. Certain types of semantic information, which are not stated
explicitly in the text, must also be taken into account. In particular, such
information is shown by typographic effects which do not correspond to a
change between structural elements. In fact, certain titles are set in bold
or italic or are printed in a different typeface from the rest of the text in
order to mark them as structurally distinct. But these same effects
frequently appear in the middle of continuous text (e.g. in the interior of a
paragraph). In this case, there is no change between structural elements; the
effect serves to highlight a word, expression, or phrase. The notion of an
<EM>attribute</EM> is used to express this type of information.</P>
<P>
An attribute is a piece of information attached to a structural element which
augments the type of the element and clarifies its function in the document.
Keywords, foreign language words, and titles of other works can all be
represented by character strings with attached attributes. Attributes may
also be attached to constructed elements. Thus, an attribute indicating the
language can be attached to a single word or to a large part of a
document.</P>
<P>
In fact, an attribute can be any piece of information which is linked to a
part of a document and which can be used by agents which work on the document.
For example, the language in which the document is written determines the set
of characters used by an editor or formatter. It also determines the
algorithm or hyphenation dictionary to be used. The attribute ``keyword''
facilitates the work of an information retrieval system. The attribute
``index word'' allows a formatter to automatically construct an index at the
end of the document.</P>
<P>
As with the types of constructed elements, the attributes and the values they
can take are defined separately in each generic logical structure, not in the
meta-model, according to the needs of the document class or the nature of the
object.</P>
<P>
Many types of attributes are offered: numeric, textual, references, and
enumerations:</P>
<UL>
<LI><EM>Numeric attributes</EM> can take integer values (negative, positive,
or null).
<LI><EM>Textual attributes</EM> have as their values character strings.
<LI><EM>Reference attributes</EM> designate an element of the logical
structure.
<LI><EM>Enumeration attributes</EM> can take one value from a limited list of
possible values, each value being a name.
</UL>
<P>
In a generic structure, there is a distinction between <EM>global
attributes</EM> and <EM>local attributes</EM>. A global attribute can be
applied to every element type defined in the generic structure where it is
specified. In contrast, a local attribute can only be applied to certain
types of elements, even only a single type. The ``language'' attribute
presented above is an example of a global attribute. An example of a local
attribute is the rank of an author (principal author of the document or
secondary author): this attribute can only be applied sensibly to an element
of the ``author'' type.</P>
<P>
Attributes can be assigned to the elements which make up the document in many
different ways. The author can freely and dynamically place them on any part
of the document in order to attach supplementary information of his choice.
However, attributes may only be assigned in accordance with the rules of the
generic structure; in particular, local attributes can only be assigned to
those element types for which they are defined.</P>
<P>
In the generic structure, certain local attributes can be made mandatory for
certain element types. In this case, Thot automatically associates the
attribute with the elements of this type and it requires the user to provide a
value for this attribute.</P>
<P>
Attributes can also be automatically assigned, with a given value, by every
application processing the document in order to systematically add a piece of
information to certain predefined elements of the document. By way of
example, in a report containing a French abstract and an English abstract,
each of the two abstracts is defined as a sequence of paragraphs. The first
abstract has a value of ``French'' for the ``language'' attribute while the
second abstract's ``language'' attribute has a value of ``English''.</P>
<P>
In the case of mark pairs, attributes are logically associated with the pair
as a whole, but are actually attached to the first mark.</P>
</DIV>
<DIV class="subsection">
<H3>Discussion of the model</H3>
<P>
The notions of attribute, constructor, structured element, and associated
element are used in the definition of generic logical structures of documents
and objects. The problem is to assemble them to form generic structures. In
fact, many types of elements and attributes can be found in a variety of
generic structures. Rather than redefine them for each structure in which
they appear, it is best to share them between structures. The object classes
already fill this sharing function. If a mathematical class is defined, its
formulas can be used in many different document classes, without redefining
the structure of each class. This problem arises not only for the objects
considered here; it also arises for the commonplace textual elements found in
many document classes. This is the reason why the notion of object is so
broad and why paragraphs and enumerations are also considered to be objects.
These object classes not only permit the sharing of the structures of
elements, but also of the attributes defined in the generic structures.</P>
<P>
Structure, such as that presented here, can appear very rigid, and it is
possible to imagine that a document editing system based on this model could
prove very constraining to the user. This is, in fact, a common criticism of
syntax-directed editors. This defect can be avoided with Thot, primarily for
three reasons:</P>
<UL>
<LI>the generic structures are not fixed in the model itself,
<LI>the model takes the dynamics of documents into account,
<LI>the constructors offer great flexibility.
</UL>
<P>
When the generic structure of a document is not predefined, but rather is
constructed specifically for each document class, it can be carefully adapted
to the current needs. In cases where the generic structure is inadequate for
a particular document of the class, it is always possible either to create a
new class with a generic structure well suited to the new case or to extend
the generic structure of the existing class to take into account the specifics
of the document which poses the problem. These two solutions can also be
applied to objects whose structures prove to be poorly designed.</P>
<P>
The model is sufficiently flexible to take into account all the phases of the
life of the document. When a generic structure specifies that a report must
contain a title, an abstract, an introduction, at least two chapters, and a
conclusion, this means only that a report, <EM>upon completion</EM>, will have
to contain all of these elements. When the author begins writing, none of
these elements is present. Thot uses this model. Therefore, it tolerates
documents which do not conform strictly to the generic structure of their
class; it also considers the generic logical structure to be a way of helping
the user in the construction of a complex document.</P>
<P>
In contrast, other applications may reject a document which does not conform
strictly to its generic structure. This is, for example, what is done by
compilers which refuse to generate code for a program which is not
syntactically correct. This might also occur when using a document
application for a report which does not have an abstract or title.</P>
<P>
The constructors of the document model bring a great flexibility to the
generic structures. A choice constructor (and even more, a unit or schema
constructor) can represent several, very different elements. The list
constructor permits the addition of more elements of the same type. Used
together, these two constructors permit any series of elements of different
types. Of course, this flexibility can be reduced wherever necessary since a
generic structure can limit the choices or the number of elements in a
list.</P>
<P>
Another difficulty linked to the use of structure in the document model
resides in the choice of the level of the structure. The structure of a
discussion could be extracted from the text itself via linguistic analysis.
Some studies are exploring this approach, but the model of Thot excludes this
type of structure. It only takes into account the logical structure provided
explicitly by the author.</P>
<P>
However, the level of structure of the model is not imposed. Each generic
structure defines its own level of structure, adapted to the document class or
object and to the ways in which it will be processed. If it will only be
edited and printed, a relatively simple structure suffices. If more
specialized processing will be applied to it, the structure must represent the
element types on which this processing must act. By way of example, a simple
structure is sufficient for printing formulas, but a more complex structure is
required to perform symbolic or numeric calculations on the mathematical
expressions. The document model of Thot allows both types of structure.</P>
</DIV>
</DIV>
<DIV class="section">
<H2>The definition language for generic structures</H2>
<P>
Generic structures, which form the basis of the document model of Thot, are
specified using a special language. This definition language, called S, is
described in this section.</P>
<P>
Each generic structure, which defines a class of documents or objects, is
specified by a file, written in the S language, which is called a
<EM>structure schema</EM>. Structure schemas are compiled into tables, called
structure tables, which are used by Thot and which determine its behavior.</P>
<DIV class="subsection">
<H3><A name="metalang">Writing Conventions</A></H3>
<P>
The grammar of S, like those of the languages P and T presented later, is
described using the meta-language M, derived from the Backus-Naur Form
(BNF).</P>
<P>
In this meta-language each rule of the grammar is composed of a grammar symbol
followed by an equals sign (`=') and the right part of the rule. The equals
sign plays the same role as the traditional `::=' of BNF: it indicates that
the right part defines the symbol of the left part. In the right part,</P>
<DL>
<DT>concatenation</DT>
<DD>is shown by the juxtaposition of symbols;
</DD>
<DT>character strings</DT>
<DD>between apostrophes ' represent terminal symbols, that is, keywords in the
language defined. Keywords are written here in upper-case letters, but can be
written in any combination of upper and lower-case letters. For example, the
keyword <TT>DEFPRES</TT> of S can also be written as <TT>defpres</TT> or
<TT>DefPres</TT>.
</DD>
<DT>material between brackets</DT>
<DD>(`[' and `]') is optional;
</DD>
<DT>material between angle brackets</DT>
<DD>(`<' and `>') can be repeated many times or omitted;
</DD>
<DT>the slash</DT>
<DD>(`/') indicates an alternative, a choice between the options separated by
the slash character;
</DD>
<DT>the period</DT>
<DD>marks the end of a rule;
</DD>
<DT>text between braces</DT>
<DD>(`{' and `}') is simply a comment.
</DD>
</DL>
<P>
The M meta-language also uses the concepts of identifiers, strings, and
integers:</P>
<DL>
<DT><TT>NAME</TT></DT>
<DD>represents an identifier, a sequence of letters (upper or lower-case),
digits, and underline characters (`_'), beginning with a letter. Also
considered a letter is the sequence of characters `<TT>\nnn</TT>' where the
letter <TT>n</TT> represents the ISOLatin 1 code of the letter in octal. It
is thus possible to use accented letters in identifiers. The maximum length
of identifiers is fixed by the compiler. It is normally 31 characters.
<P>
Unlike keywords, upper and lower-case letters are distinct in identifiers.
Thus, <TT>Title</TT>, <TT>TITLE</TT>, and <TT>title</TT> are considered
different identifiers.</P>
</DD>
<DT><TT>STRING</TT></DT>
<DD>represents a string. This is a string of characters delimited by
apostrophes. If an apostrophe must appear in a string, it is doubled. As
with identifiers, strings can contain characters represented by their octal
code (after a backslash). As with apostrophes, if a backslash must appear in
a string, it is doubled.
</DD>
<DT><TT>NUMBER</TT></DT>
<DD>represents a positive integer or zero (without a sign), or said another
way, a sequence of decimal digits.
</DD>
</DL>
<P>
The M language can be used to define itself as follows:</P>
<PRE>
{ Any text between braces is a comment. }
Grammar = Rule < Rule > 'END' .
{ The < and > signs indicate zero }
{ or more repetitions. }
{ END marks the end of the grammar. }
Rule = Ident '=' RightPart '.' .
{ The period indicates the end of a rule }
RightPart = RtTerminal / RtIntermed .
{ The slash indicates a choice }
RtTerminal ='NAME' / 'STRING' / 'NUMBER' .
{ Right part of a terminal rule }
RtIntermed = Possibility < '/' Possibility > .
{ Right part of an intermediate rule }
Possibility = ElemOpt < ElemOpt > .
ElemOpt = Element / '[' Element < Element > ']' /
'<' Element < Element > '>' .
{ Brackets delimit optional parts }
Element = Ident / KeyWord .
Ident = NAME .
{ Identifier, sequence of characters }
KeyWord = STRING .
{ Character string delimited by apostrophes }
END
</PRE>
</DIV>
<DIV class="subsection">
<H3><A name="extsch">Extension schemas</A></H3>
<P>
A structure schema defines the generic logical structure of a class of
documents or objects, independent of the operations which can be performed on
the documents. However, certain applications may require particular
information to be represented by the structure for the documents that they
operate on. Thus a document version manager will need to indicate in the
document the parts which belong to one version or another. An indexing system
will add highly-structured index tables as well as the links between these
tables and the rest of the document.</P>
<P>
Thus, many applications need to extend the generic structure of the documents
on which they operate to introduce new attributes, associated elements or
element types. These additions are specific to each application and must be
able to be applied to any generic structure: users will want to manage
versions or construct indices for many types of documents. Extension schemas
fulfill this role: they define attributes, elements, associated elements,
units, etc., but they can only be used jointly with a structure schema that
they complete. Otherwise, structure schemas can always be used without these
extensions when the corresponding applications are not available.</P>
</DIV>
<DIV class="subsection">
<H3>The general organization of structure schemas</H3>
<P>
Every structure schema begins with the keyword <TT>STRUCTURE</TT> and ends
with the keyword <TT>END</TT>. The keyword <TT>STRUCTURE</TT> is followed by
the keyword <TT>EXTENSION</TT> in the case where the schema defines an
extension, then by the name of the generic structure which the schema defines
(the name of the document or object class). The name of the structure is
followed by a semicolon.</P>
<P>
In the case of a complete schema (that is, a schema which is not an
extension), the definition of the name of the structure is followed by the
declarations of the default presentation schema, the global attributes, the
parameters, the structure rules, the associated elements, the units, the
skeleton elements and the exceptions. Only the definition of the structure
rules is required. Each series of declarations begins with a keyword:
<TT>DEFPRES</TT>, <TT>ATTR</TT>, <TT>PARAM</TT>, <TT>STRUCT</TT>,
<TT>ASSOC</TT>, <TT>UNITS</TT>, <TT>EXPORT</TT>, <TT>EXCEPT</TT>.</P>
<P>
In the case of an extension schema, there are neither parameters nor skeleton
elements and the <TT>STRUCT</TT> section is optional, while that section is
required in a schema that is not an extension. On the other hand, extension
schemas can contain an <TT>EXTENS</TT> section, which must not appear in a
schema which is not an extension; this section defines the complements to
attach to the rules found in the schema to which the extension will be added.
The sections <TT>ATTR</TT>, <TT>STRUCT</TT>, <TT>ASSOC</TT>, and
<TT>UNITS</TT> define new attributes, new elements, new associated elements,
and new units which add their definitions to the principal schema.</P>
<PRE>
StructSchema ='STRUCTURE' ElemID ';'
'DEFPRES' PresID ';'
[ 'ATTR' AttrSeq ]
[ 'PARAM' RulesSeq ]
'STRUCT' RulesSeq
[ 'ASSOC' RulesSeq ]
[ 'UNITS' RulesSeq ]
[ 'EXPORT' SkeletonSeq ]
[ 'EXCEPT' ExceptSeq ]
'END' .
ElemID = NAME .
</PRE>
<P>
or</P>
<PRE>
ExtensSchema ='STRUCTURE' 'EXTENSION' ElemID ';'
'DEFPRES' PresID ';'
[ 'ATTR' AttrSeq ]
[ 'STRUCT' RulesSeq ]
[ 'EXTENS' ExtensRuleSeq ]
[ 'ASSOC' RulesSeq ]
[ 'UNITS' RulesSeq ]
[ 'EXCEPT' ExceptSeq ]
'END' .
ElemID = NAME .
</PRE>
</DIV>
<DIV class="subsection">
<H3>The default presentation</H3>
<P>
It was shown <A href="#mulpres">above</A> that many different presentations
are possible for documents and objects of the same class. The structure
schema defines a preferred presentation for the class, called the <EM>default
presentation</EM>. Like generic structures, presentations are described by
programs, called <EM>presentation schemas</EM>, which are written in a
specific language, P, presented <A href="#langp">later</A> in this document.
The name appearing after the keyword <TT>DEFPRES</TT> is the name of the
default presentation schema. When a new document is created, Thot will use
this presentation schema by default, but the user remains free to choose
another if he wishes.</P>
<PRE>
PresID = NAME .
</PRE>
</DIV>
<DIV class="subsection">
<H3><A name="globalattr">Global Attributes</A></H3>
<P>
If the generic structure includes global attributes of its own, they are
declared after the keyword <TT>ATTR</TT>. Each global attribute is defined by
its name, followed by an equals sign and the definition of its type. The
declaration of a global attribute is terminated by a semi-colon.</P>
<P>
For attributes of the numeric, textual, or reference types, the type is
indicated by a keyword, <TT>INTEGER</TT>, <TT>TEXT</TT>, or <TT>REFERENCE</TT>
respectively.</P>
<P>
In the case of a reference attribute, the keyword <TT>REFERENCE</TT> is
followed by the type of the referenced element in parentheses. It can refer
to any type at all, specified by using the keyword <TT>ANY</TT>, or to a
specific type. In the latter case, the element type designated by the
reference can be defined either in the <A href="#structelem"><TT>STRUCT</TT>
section</A> of the same structure schema or in the <TT>STRUCT</TT> section of
another structure schema. When the type is defined in another schema, the
element type is followed by the name of the structure schema (within
parentheses) in which it is defined. The name of the designated element type
can be preceded by the keyword <TT>First</TT> or <TT>Second</TT>, but only in
the case where the type is defined as <A href="#pairs">a pair</A>. These
keywords indicate whether the attribute must designate the first mark of the
pair or the second. If the reference refers to a pair and neither of these
two keywords is present, then the first mark is used.</P>
<P>
In the case of an enumeration attribute, the equals sign is followed by the
list of names representing the possible values of the attribute, the names
being separated from each other by commas. An enumeration attribute has at
least one possible value; the maximum number of values is defined by the
compiler for the S language.</P>
<PRE>
AttrSeq = Attribute < Attribute > .
Attribute = AttrID '=' AttrType ';' .
AttrType = 'INTEGER' / 'TEXT' /
'REFERENCE' '(' RefType ')' /
ValueSeq .
RefType = 'ANY' / [ FirstSec ] ElemID [ ExtStruct ] .
FirstSec = 'First' / 'Second' .
ExtStruct = '(' ElemID ')' .
ValueSeq = AttrVal < ',' AttrVal > .
AttrID = NAME .
AttrVal = NAME .
</PRE>
<P>
There is a predefined global text attribute, the <EM>language</EM>, which is
automatically added to every Thot structure schema. This attribute allows
Thot to perform certain actions, such as hyphenation and spell-checking, which
cannot be performed without knowing the language in which each part of the
document is written. This attribute can be used just like any explicitly
declared attribute: the system acts as if every structure schema contains</P>
<PRE>
ATTR
Language = TEXT;
</PRE>
<BLOCKQUOTE class="example">
<P>
<STRONG>Example:</STRONG></P>
<P>
The following specification defines the global enumeration attribute
WordType.</P>
<PRE>
ATTR
WordType = Definition, IndexWord, DocumentTitle;
</PRE>
</BLOCKQUOTE>
</DIV>
<DIV class="subsection">
<H3><A name="param">Parameters</A></H3>
<P>
A parameter is a document element which can appear many times in the document,
but always has the same value. This value can only be modified in a
controlled way by certain applications. For example, in an advertising
circular, the name of the recipient may appear in the address part and in the
text of the circular. If the recipient's name were a parameter, it might only
be able to be changed by a ``mail-merge'' application.</P>
<P>
Parameters are not needed for every document class, but if the schema includes
parameters they are declared after the keyword <TT>PARAM</TT>. Each parameter
declaration is made in the same way as a <A href="#structelem">structure
element declaration</A>.</P>
<P>
During editing, Thot permits the insertion of parameters wherever the
structure schema allows; it also permits the removal of parameters which are
already in the document but does not allow the modification of the parameter's
content in any way. The content is generated automatically by Thot during the
creation of the parameter, based on the value of the parameter in the
document.</P>
</DIV>
<DIV class="subsection">
<H3><A name="structelem">Structured elements</A></H3>
<P>
The rules for defining structured elements are required, except in an
extension schema: they constitute the core of a structure schema, since they
define the structure of the different types of elements that occur in a
document or object of the class defined by the schema.</P>
<P>
The first structure rule after the keyword <TT>STRUCT</TT> must define the
structure of the class whose name appears in the first instruction
(<TT>STRUCTURE</TT>) of the schema. This is the root rule of the schema,
defining the root of the document tree or object tree.</P>
<P>
The remaining rules may be placed in any order, since the language permits the
definition of element types before or after their use, or even in the same
instruction in which they are used. This last case allows the definition of
recursive structures.</P>
<P>
Each rule is composed of a name (the name of the element type whose structure
is being defined) followed by an equals sign and a structure definition.</P>
<P>
If any local attributes are associated with the element type defined by the
rule, they appear between parentheses after the type name and before the
equals sign. The parentheses contain, first, the keyword <TT>ATTR</TT>, then
the list of local attributes, separated by commas. Each local attribute is
composed of the name of the attribute followed by an equals sign and the
definition of the attribute's type, just as in the definition of <A
href="#globalattr">global attributes</A>. The name of the attribute can be
preceded by an exclamation point to indicate that the attribute must always be
present for this element type. The same attribute, identified by its name,
can be defined as a local attribute for multiple element types. In this
case, the equals sign and definition of the attribute type need only appear in
the first occurrence of the attribute. It should be noted that global
attributes cannot also be defined as local attributes.</P>
<P>
If any <A href="#restrictionextensions">extensions</A> are defined for this
element type, a plus sign follows the structure definition and the names of
the extension element types appear between parentheses after the plus. If
there are multiple extensions, they are separated by commas. These types can
either be defined in the same schema, defined in other schemas, or they may be
base types identified by the keywords <TT>TEXT</TT>, <TT>GRAPHICS</TT>,
<TT>SYMBOL</TT>, or <TT>PICTURE</TT>.</P>
<P>
<A href="#restrictionextensions">Restrictions</A> are indicated in the same
manner as extensions, but they are introduced by a minus sign and they come
after the extensions, or if there are no extensions, after the structure
definition.</P>
<P>
If the values of attributes must be attached systematically to this element
type, they are introduced by the keyword <TT>WITH</TT> and declared in the
form of a list of fixed-value attributes. When such definitions of fixed
attribute values appear, they are always the last part of the rule.</P>
<P>
The rule is terminated by a semicolon.</P>
<PRE>
RuleSeq = Rule < Rule > .
Rule = ElemID [ LocAttrSeq ] '=' DefWithAttr ';'.
LocAttrSeq = '(' 'ATTR' LocAttr < ';' LocAttr > ')' .
LocAttr = [ '!' ] AttrID [ '=' AttrType ] .
DefWithAttr = Definition
[ '+' '(' ExtensionSeq ')' ]
[ '-' '(' RestrictSeq ')' ]
[ 'WITH' FixedAttrSeq ] .
ExtensionSeq = ExtensionElem < ',' ExtensionElem > .
ExtensionElem = ElemID / 'TEXT' / 'GRAPHICS' /
'SYMBOL' / 'PICTURE' .
RestrictSeq = RestrictElem < ',' RestrictElem > .
RestrictElem = ElemID / 'TEXT' / 'GRAPHICS' /
'SYMBOL' / 'PICTURE' .
</PRE>
<P>
The list of fixed-value attributes is composed of a sequence of
attribute-value pairs separated by commas. Each pair contains the name of the
attribute and the fixed value for this element type, the two being separated
by an equals sign. If the sign is preceded by a question mark the given value
is only an initial value that may be modified later rather than a value fixed
for all time. Reference attributes are an exception to this norm. They
cannot be assigned a fixed value, but when the name of such an attribute
appears this indicates that this element type must have a valid value for the
attribute. For the other attribute types, the fixed value is indicated by a
signed integer (numeric attributes), a character string between apostrophes
(textual attributes) or the name of a value (enumeration attributes).</P>
<P>
Fixed-value attributes can either be <A href="#globalattr">global</A> or local
to the element type for which they are fixed, but they must be declared before
they are used.</P>
<PRE>
FixedAttrSeq = FixedAttr < ',' FixedAttr > .
FixedAttr = AttrID [ FixedOrModifVal ] .
FixedOrModifVal = [ '?' ] '=' FixedValue .
FixedValue = [ '-' ] NumValue / TextVal / AttrVal .
NumValue = NUMBER .
TextVal = STRING .
</PRE>
</DIV>
<DIV class="subsection">
<H3><A name="structdef">Structure definitions</A></H3>
<P>
The structure of an element type can be a simple base type or a constructed
type.</P>
<P>
For constructed types, it is frequently the case that similar structures
appear in many places in a document. For example the contents of the
abstract, of the introduction, and of a section can have the same structure,
that of a sequence of paragraphs. In this case, a single, common structure
can be defined (the paragraph sequence in this example), and the schema is
written to indicate that each element type possesses this structure, as
follows:</P>
<PRE>
Abstract = Paragraph_sequence;
Introduction = Paragraph_sequence;
Section_contents = Paragraph_sequence;
</PRE>
<P>
The equals sign means ``has the same structure as''.</P>
<P>
If the element type defined is a simple base type, this is indicated by one of
the keywords <TT>TEXT</TT>, <TT>GRAPHICS</TT>, <TT>SYMBOL</TT>, or
<TT>PICTURE</TT>. If some local attributes must be associated with a base
type, the keyword of the base type is followed by the declaration of the local
attributes using the syntax <A href="#structelem">presented above.</A></P>
<P>
In the case of an open choice, the type is indicated by the keyword
<TT>UNIT</TT> for units or the keyword <TT>NATURE</TT> for objects having a
structure defined by any other schema.</P>
<P>
A unit represents one of the two following categories:</P>
<UL>
<LI>a base type: text, graphical element, symbol, picture,
<LI>an element whose type is chosen from among the types defined as units in
the <TT>UNITS</TT>section of the document's structure schema. It can also be
chosen from among the types defined as <A href="#schemasandunits">units</A> in
the <A href="#units"><TT>UNITS</TT> section</A> of the structure schemas that
defines the ancestors of the element to which the rule is applied.
</UL>
<P>
Before the creation of an element defined as a unit, Thot asks the user to
choose between the categories of elements.</P>
<P>
Thus, the contents of a paragraph can be specified as a sequence of units,
which will permit the inclusion in the paragraphs of character strings,
symbols, and various elements, such as cross-references, if these are defined
as units.</P>
<P>
A schema object (keyword <TT>NATURE</TT>) represents an object defined by a
structure schema freely chosen from among the available schemas; in the case
the element type is defined by the first rule (the root rule) of the chosen
schema.</P>
<P>
If the element type defined is a constructed type, the list, aggregate,
choice, and reference constructors are used. In this case the definition
begins with a keyword identifying the constructor. This keyword is followed
by a syntax specific to each constructor.</P>
<P>
The local attribute definitions appear after the name of the element type
being defined, if this element type has <A href="#structelem">local
attributes</A>.</P>
<PRE>
Definition = BaseType [ LocAttrSeq ] / Constr / Element .
BaseType = 'TEXT' / 'GRAPHICS' / 'SYMBOL' / 'PICTURE' /
'UNIT' / 'NATURE' .
Element = ElemID [ ExtOrDef ] .
ExtOrDef = 'EXTERN' / 'INCLUDED' /
[ LocAttrSeq ] '=' Definition .
Constr = 'LIST' [ '[' min '..' max ']' ] 'OF'
'(' DefWithAttr ')' /
'BEGIN' DefOptSeq 'END' /
'AGGREGATE' DefOptSeq 'END' /
'CASE' 'OF' DefSeq 'END' /
'REFERENCE' '(' RefType ')' /
'PAIR' .
</PRE>
<DIV class="subsubsection">
<H4>List</H4>
<P>
The list constructor permits the definition of an element type composed of a
list of elements, all of the same type. A list definition begins with the
<TT>LIST</TT> keyword followed by an optional range, the keyword <TT>OF</TT>,
and the definition, between parentheses, of the element type which must
compose the list. The optional range is composed of the minimum and maximum
number of elements for the list separated by two periods and enclosed by
brackets. If the range is not present, the number of list elements is
unconstrained. When only one of the two bounds of the range is unconstrained,
it is represented by a star ('*') character. Even when both bounds are
unconstrained, they can be specified by <TT>[*..*]</TT>, but it is simpler not
to specify any bound.</P>
<PRE>
'LIST' [ '[' min '..' max ']' ]
'OF' '(' DefWithAttr ')'
min = Integer / '*' .
max = Integer / '*' .
Integer = NUMBER .
</PRE>
<P>
Before the document is edited, Thot creates the minimum number of elements for
the list. If no minimum was given, it creates a single element. If a maximum
number of elements is given and that number is attained, the editor refuses to
create new elements for the list.</P>
<BLOCKQUOTE class="example">
<P>
<STRONG>Example:</STRONG></P>
<P>
The following two instructions define the body of a document as a sequence of
at least two chapters and the contents of a section as a sequence of
paragraphs. A single paragraph can be the entire contents of a section.</P>
<PRE>
Body = LIST [2..*] OF (Chapter);
Section_contents = LIST OF (Paragraph);
</PRE>
</BLOCKQUOTE>
</DIV>
<DIV class="subsubsection">
<H4>Aggregate</H4>
<P>
The aggregate constructor is used to define an element type as a collection of
sub-elements, each having a fixed type. The collection may be ordered or
unordered. The elements composing the collection are called
<EM>components</EM>. In the definition of an aggregate, a keyword indicates
whether or not the aggregate is ordered: <TT>BEGIN</TT> for an ordered
aggregate, <TT>AGGREGATE</TT> for an unordered aggregate. This keyword is
followed by the list of component type definitions which is terminated by the
<TT>END</TT> keyword. The component type definitions are separated by
commas.</P>
<P>
Before creating an aggregate, the Thot editor creates all the aggregate's
components in the order they appear in the structure schema, even for
unordered aggregates. However, unlike ordered aggregates, the components of
an unordered aggregate may be rearranged using operations of the Thot editor.
The exceptions to the rule are any components whose name was preceded by a
question mark character ('?'). These components, which are optional, can be
created by explicit request, possibly at the time the aggregate is created,
but they are not created automatically <EM>prior</EM> to the creation of the
aggregate.</P>
<PRE>
'BEGIN' DefOptSeq 'END'
DefOptSeq = DefOpt ';' < DefOpt ';' > .
DefOpt = [ '?' ] DefWithAttr .
</PRE>
<BLOCKQUOTE class="example">
<P>
<STRONG>Example:</STRONG></P>
<P>
In a bilingual document, each paragraph has an English version and a French
version. In certain cases, the translator wants to add a marginal note, but
this note is present in very few paragraphs. Thus, it must not be created
systematically for every paragraph. A bilingual paragraph of this type is
declared:</P>
<PRE>
Bilingual_paragraph = BEGIN
French_paragraph = TEXT;
English_paragraph = TEXT;
? Note = TEXT;
END;
</PRE>
</BLOCKQUOTE>
</DIV>
<DIV class="subsubsection">
<H4>Choice</H4>
<P>
The choice constructor permits the definition of an element type which is
chosen from among a set of possible types. The keywords <TT>CASE</TT> and
<TT>OF</TT> are followed by a list of definitions of possible types, which are
separated by semicolons and terminated by the <TT>END</TT> keyword.</P>
<PRE>
'CASE' 'OF' DefSeq 'END'
DefSeq = DefWithAttr ';' < DefWithAttr ';' > .
</PRE>
<P>
Before the creation of an element defined as a choice, the Thot editor
presents the list of possible types for the element to the user. The user has
only to select the element type that he wants to create from this list.</P>
<P>
The order of the type declarations is important. It determines the order of
the list presented to the user before the creation of the element. Also, when
a Choice element is being created automatically, the first type in the list is
used. In fact, using the Thot editor, when an empty Choice element is
selected, it is possible to select this element and to enter its text from
keyboard. In this case, the editor uses the first element type which can
contain an atom of the character string type.</P>
<P>
The two special cases of the choice constructor, the <A
href="#structdef"><EM>schema</EM></A> and the <A
href="#units"><EM>unit</EM></A> are discussed elsewhere.</P>
<BLOCKQUOTE class="example">
<P>
<STRONG>Example:</STRONG></P>
<P>
It is common in documents to treat a variety of objects as if they were
ordinary paragraphs. Thus, a ``Paragraph'' might actually be composed of a
block of text (an ordinary paragraph), or a mathematical formula whose
structure is defined by another structure schema named Math, or a table, also
defined by another structure schema. Here is a definition of such a
paragraph:</P>
<PRE>
Paragraph = CASE OF
Simple_text = TEXT;
Formula = Math;
Table_para = Table;
END;
</PRE>
</BLOCKQUOTE>
</DIV>
<DIV class="subsubsection">
<H4><A name="references">Reference</A></H4>
<P>
Like all elements in Thot, references are typed. An element type defined as a
reference is a cross-reference to an element of some other given type. The
keyword <TT>REFERENCE</TT> is followed by the name of a type enclosed in
parentheses. When the type which is being cross-referenced is defined in
another structure schema, the type name is itself followed by the name of the
external structure schema in which it is defined.</P>
<P>
When the designated element type is a <A href="#pairs">mark pair</A>, it can
be preceded by a <TT>FIRST</TT> or <TT>SECOND</TT> keyword. These keywords
indicate whether the reference points to the first or second mark of the pair.
If the reference points to a pair and neither of these two keywords is
present, the reference is considered to point to the first mark of the
pair.</P>
<P>
There is an exception to the principle of typed references: it is possible to
define a reference which designates an element of any type, which can either
be in the same document or another document. In this case, it suffices to put
the keyword <TT>ANY</TT> in the parentheses which indicate the referenced
element type.</P>
<PRE>
'REFERENCE' '(' RefType ')'
RefType = 'ANY' / [ FirstSec ] ElemID [ ExtStruct ] .
</PRE>
<P>
When defining an inclusion, the <TT>REFERENCE</TT> keyword is not used.
Inclusions with complete expansion are not declared as such in the structure
schemas, since any element defined in a structure schema can be replaced by an
element of the same type. Instead, inclusions without expansion or with
partial expansion must be declared explicitly whenever they will include a
complete object ( and not a part of an object). In this case, the object type
to be included (that is, the name of its structure schema) is followed by a
keyword: <TT>EXTERN</TT> for inclusion without expansion and <TT>INCLUDED</TT>
for partial expansion.</P>
<P>
Before creating a cross-reference or an inclusion, the Thot editor asks the
user to choose, from the document images displayed, the referenced or included
element.</P>
<BLOCKQUOTE class="example">
<P>
<STRONG>Example:</STRONG></P>
<P>
If the types Note and Section are defined in the Article structure schema, it
is possible to define, in the same structure schema, a reference to a note and
a reference to a section in this manner:</P>
<PRE>
Ref_note = REFERENCE (Note);
Ref_section = REFERENCE (Section);
</PRE>
<P>
It is also possible to define the generic structure of a collection of
articles, which include (with partial expansion) objects of the Article class
and which possess an introduction which may include cross-references to
sections of the included articles. In the Collection structure schema, the
definitions are:</P>
<PRE>
Collection = BEGIN
Collection_title = TEXT;
Introduction = LIST OF (Elem = CASE OF
TEXT;
Ref_sect;
END);
Body = LIST OF (Article INCLUDED);
END;
Ref_sect = REFERENCE (Section (Article));
</PRE>
<P>
Here we define a Folder document class which has a title and includes
documents of different types, particularly Folders:</P>
<PRE>
Folder = BEGIN
Folder_title = TEXT;
Folder_contents = LIST OF (Document);
END;
Document = CASE OF
Article EXTERN;
Collection EXTERN;
Folder EXTERN;
END;
</PRE>
<P>
Under this definition, Folder represents either an aggregate which contains a
folder title and the list of included documents or an included folder. To
resolve this ambiguity, in the P language, the placement of a star character
in front of the type name (here, Folder) indicates an included document.</P>
</BLOCKQUOTE>
</DIV>
<DIV class="subsubsection">
<H4><A name="pairs">Mark pairs</A></H4>
<P>
Like other elements, mark pairs are typed. The two marks of the pair have the
same type, but there exist two predefined subtypes which apply to all mark
pairs: the first mark of the pair (called <TT>First</TT> in the P and T
languages) and the second mark (called <TT>Second</TT>).</P>
<P>
In the S language, a mark pair is noted simply by the <TT>PAIR</TT>
keyword.</P>
<P>
In the Thot editor, marks are always moved or destroyed together. The two
marks of a pair have the same identifier, unique within the document, which
permits intertwining mark pairs without risk of ambiguity.</P>
</DIV>
</DIV>
<DIV class="subsection">
<H3>Imports</H3>
<P>
Because of schema constructors, it is possible, before editing a document, to
use classes defined by other structure schemas whenever they are needed. It is
also possible to assign specific document classes to certain element types. In
this case, these classes are simply designated by their name. In fact, if a
type name is not defined in the structure schema, it is assumed that it
specifies a structure defined by another structure schema.</P>
<BLOCKQUOTE class="example">
<P>
<STRONG>Example:</STRONG></P>
<P>
If the types Math and Table don't appear in the left part of a structure rule
in the schema, the following two rules indicate that a formula has the
structure of an object defined by the structure schema Math and that a table
element has the structure of an object defined by the Table schema.</P>
<PRE>
Formula = Math;
Table_elem = Table;
</PRE>
</BLOCKQUOTE>
</DIV>
<DIV class="subsection">
<H3>Extension rules</H3>
<P>
The <TT>EXTENS</TT> section, which can only appear in an extension schema,
defines complements to the rules in the primary schema (i.e. the structure
schema to which the extension schema will be applied). More precisely, this
section permits the addition to an existing type of local attributes,
extensions, restrictions and fixed-value attributes.</P>
<P>
These additions can be applied to the root rule of the primary schema,
designated by the keyword <TT>Root</TT>, or to any other explicitly named
rule.</P>
<P>
Extension rules are separated from each other by a semicolon and each
extension rule has the same syntax as a <A href="#structelem">structure
rule</A>, but the part which defines the constructor is absent.</P>
<PRE>
ExtenRuleSeq = ExtensRule ';' < ExtensRule ';' > .
ExtensRule = RootOrElem [ LocAttrSeq ]
[ '+' '(' ExtensionSeq ')' ]
[ '-' '(' RestrictSeq ')' ]
[ 'WITH' FixedAttrSeq ] .
RootOrElem = 'Root' / ElemID .
</PRE>
</DIV>
<DIV class="subsection">
<H3>Associated elements</H3>
<P>
If associated elements are necessary, they must be declared in a specific
section of the structure schema, introduced by the keyword <TT>ASSOC</TT>.
Each associated element type is specified like any other structured element.
However, these types must not appear in any other element types of the schema,
except in <TT>REFERENCE</TT> rules.</P>
</DIV>
<DIV class="subsection">
<H3><A name="units">Units</A></H3>
<P>
The <TT>UNITS</TT> section of the structure schema contains the declarations
of the element types which can be used in the external objects making up parts
of the document or in objects of the class defined by the schema. As with
associated elements, these element types are defined just like other
structured element types. They can be used in the other element types of the
schema, but they can also be used in any other rule of the schema.</P>
<BLOCKQUOTE class="example">
<P>
<STRONG>Example:</STRONG></P>
<P>
If references to notes are declared as units:</P>
<PRE>
UNITS
Ref_note = REFERENCE (Note);
</PRE>
<P>
then it is possible to use references to notes in a cell of a table, even when
<TT>Table</TT> is an external structure schema. The <TT>Table<TT> schema must
declare a cell to be a sequence of units, which can then be base element types
(text, for example) or references to notes in the document. <PRE>
Cell = LIST OF (UNITS);
</PRE>
</TT></TT></P>
</BLOCKQUOTE>
</DIV>
<DIV class="subsection">
<H3><A name="skeleton">Skeleton elements</A></H3>
<P>
When editing a document which contains or must contain external references to
several other documents, it may be necessary to load a large number of
documents, simply to see the parts designated by the external references of
the document while editing, or to access the source of included elements. In
this case, the external documents are not modified and it is only necessary to
see the elements of these documents which could be referenced. Because of
this, the editor will suggest that the documents be loaded in ``skeleton''
form. This form contains only the elements of the document explicitly
mentioned in the <TT>EXPORT</TT> section of their structure schema and, for
these elements, only the part of the contents specified in that section. This
form has the advantage of being very compact, thus requiring very few
resources from the editor. This is also the skeleton form which constitutes
the expanded form of <A href="#inclusion">inclusions</A> with partial
expansion.</P>
<P>
Skeleton elements must be declared explicitly in the <TT>EXPORT</TT> section
of the structure schema that defines them. This section begins with the
keyword <TT>EXPORT</TT> followed by a comma-separated list of the element
types which must appear in the skeleton form and ending with a semicolon.
These types must have been previously declared in the schema.</P>
<P>
For each skeleton element type, the part of the contents which is loaded by
the editor, and therefore displayable, can be specified by putting the keyword
<TT>WITH</TT> and the name of the contained element type to be loaded after
the name of the skeleton element type. In this case only that named element,
among all the elements contained in the exportable element type, will be
loaded. If the <TT>WITH</TT> is absent, the entire contents of the skeleton
element will be loaded by the editor. If instead, it is better that the
skeleton form not load the contents of a particular element type, the keyword
<TT>WITH</TT> must be followed by the word <TT>Nothing</TT>.</P>
<PRE>
[ 'EXPORT' SkeletonSeq ]
SkeletonSeq = SkelElem < ',' SkelElem > ';' .
SkelElem = ElemID [ 'WITH' Contents ] .
Contents = 'Nothing' / ElemID [ ExtStruct ] .
</PRE>
<BLOCKQUOTE class="example">
<P>
<STRONG>Example:</STRONG></P>
<P>
Suppose that, in documents of the article class, the element types
Article_title, Figure, Section, Paragraph, and Biblio should appear in the
skeleton form in order to make it easier to create external references to them
from other documents. When loading an article in its skeleton form, all of
these element types will be loaded except for paragraphs, but only the article
title will be loaded in its entirety. For figures, the legend will be loaded,
while for sections, the title will be loaded, and for bibliographic entries,
only the title that they contain will be loaded. Note that
bibliographic elements are defined in another structure schema, RefBib. To
produce this result, the following declarations should be placed in the
Article structure schema:</P>
<PRE>
EXPORT
Article_title,
Figure With Legend,
Section With Section_title,
Paragraph With Nothing,
Biblio With Biblio_title(RefBib);
</PRE>
</BLOCKQUOTE>
</DIV>
<DIV class="subsection">
<H3>Exceptions</H3>
<P>
The behavior of the Thot editor and the actions that it performs are
determined by the structure schemas. These actions are applied to all
document and object types in accordance with their generic structure. For
certain object types, such as tables and graphics, these actions are not
sufficient or are poorly adapted and some special actions must be added to or
substituted for certain standard actions. These special actions are called
<EM>exceptions</EM>.</P>
<P>
Exceptions only inhibit or modify certain standard actions, but they can be
used freely in every structure schema.</P>
<P>
Each structure schema can contain a section defining exceptions. It begins
with the keyword <TT>EXCEPT</TT> and is composed of a sequence of exception
declarations, separated by semicolons. Each declaration of an exception
begins with the name of an element type or attribute followed by a colon. This
indicates the element type or attribute to which the following exceptions
apply. When the given element type name is a <A href="#pairs">mark pair</A>,
and only in this case, the type name can be preceded by the keyword
<TT>First</TT> or <TT>Second</TT>, to indicate if the exceptions which follow
are associated with the first mark of the pair or the second. In the absence
of this keyword, the first mark is used.</P>
<P>
When placed in an <A href="#extsch">extension schema</A>, the keyword
<TT>EXTERN</TT> indicates that the type name which follows is found in the
principal schema (the schema being extended by the extension schema). The
exceptions are indicated by a name. They are separated by semicolons.</P>
<PRE>
[ 'EXCEPT' ExceptSeq ]
ExceptSeq = Except ';' < Except ';' > .
Except = [ 'EXTERN' ] [ FirstSec ] ExcTypeOrAttr
':' ExcValSeq .
ExcTypeOrAttr = ElemID / AttrID .
ExcValSeq = ExcValue < ',' ExcValue > .
ExcValue ='NoCut' / 'NoCreate' /
'NoHMove' / 'NoVMove' / 'NoMove' /
'NoHResize' / 'NoVResize' / 'NoResize' /
'NewWidth' / 'NewHeight' /
'NewHPos' / 'NewVPos' /
'Invisible' / 'NoSelect' /
'Hidden' / 'ActiveRef' /
'ImportLine' / 'ImportParagraph' /
'NoPaginate' / 'ParagraphBreak' /
'HighlightChildren' / 'ExtendedSelection' .
</PRE>
<P>
The following are the available exceptions:</P>
<DL>
<DT><TT>NoCut</TT></DT>
<DD>This exception can only be applied to element types. Elements of a type to
which this exception is applied cannot be destroyed by the editor.
</DD>
<DT><TT>NoCreate</TT></DT>
<DD>This exception can only be applied to element types. Elements of a type to
which this exception is applied cannot be created by ordinary commands for
creating new elements. These elements are usually created by special actions
associated with otherexceptions.
</DD>
<DT><TT>NoHMove</TT></DT>
<DD>This exception can only be applied to element types. Elements of a type to
which this exception is applied cannot be moved horizontally with the mouse.
</DD>
<DT><TT>NoVMove</TT></DT>
<DD>This exception can only be applied to element types. Elements of a type to
which this exception is applied canno tbe moved vertically with the mouse.
</DD>
<DT><TT>NoMove</TT></DT>
<DD>This exception can only be applied to element types. Elements of a type to
which this exception is applied cannot be moved in any direction with the
mouse.
</DD>
<DT><TT>NoHResize</TT></DT>
<DD>This exception can only be applied to element types. Elements of a type to
which this exception is applied cannot be resized horizontally with the mouse.
</DD>
<DT><TT>NoVResize</TT></DT>
<DD>This exception can only be applied to element types. Elements of a type to
which this exception is applied cannot be resized vertically with the mouse.
</DD>
<DT><TT>NoResize</TT></DT>
<DD>This exception can only be applied to element types. Elements of a type to
which this exception is applied cannot be resized in any direction with the
mouse.
</DD>
<DT><TT>NoSelect</TT></DT>
<DD>This exception can only be applied to element types. Elements of a type to
which this exception is applied cannot be selected directly with the mouse, but
they can be selected by other methods provided by the editor.
</DD>
<DT><TT>NewWidth</TT></DT>
<DD>This exception can only be applied to numeric attributes. If the width of
an element which has this attribute is modified with the mouse, the value of
the new width will be assigned to the attribute.
</DD>
<DT><TT>NewHeight</TT></DT>
<DD>This exception can only be applied to numeric attributes. If the height of
an element which has this attribute is modified with the mouse, the value of
the new height will be assigned to the attribute.
</DD>
<DT><TT>NewHPos</TT></DT>
<DD>This exception can only be applied to numeric attributes. If the
horizontal position of an element which has this attribute is modified with the
mouse, the value of the new horizontal position will be assigned to the
attribute.
</DD>
<DT><TT>NewVPos</TT></DT>
<DD>This exception can only be applied to numeric attributes. If the vertical
position of an element which has this attribute is modified with the mouse, the
value of the new vertical position will be assigned to the attribute.
</DD>
<DT><TT>Invisible</TT></DT>
<DD>This exception can only be applied to attributes, but can be applied to all
attribute types. It indicates that the attribute must not be seen by the user
and that its value must not be changed directly. This exception is usually
used whenanother exception manipulates the value of an attribute.
</DD>
<DT><TT>Hidden</TT></DT>
<DD>This exception can only be applied to element types. It indicates that
elements of this type, although present in the document's structure, must not
be shown to the user of the editor. In particular, the creation menus must not
propose this type and the selection message must not pick it.
</DD>
<DT><TT>ActiveRef</TT></DT>
<DD>This exception can only be applied to attributes of the reference type. It
indicates that when the user of the editor makes a double click on an element
which possesses a reference attribute having this exception, the element
designated by the reference attribute will be selected.
</DD>
<DT><TT>ImportLine</TT></DT>
<DD>This exception can only be applied to element types. It indicates that
elements of this type should receive the content of imported text files. An
element is created for each line of the imported file. A structure schema
cannot contain several exceptions <TT>ImportLine</TT> and, if it contains one,
it should not contain any exception <TT>ImportParagraph</TT>.
</DD>
<DT><TT>ImportParagraph</TT></DT>
<DD>This exception can only be applied to element types. It indicates that
elements of this type should receive the content of imported text files. An
element is created for each paragraph of the imported file. A paragraph is a
sequence of lines without any empty line. A structure schema cannot contain
several exceptions <TT>ImportParagraph</TT> and, if it contains one, it should
not contain any exception <TT>ImportLine</TT>.
</DD>
<DT><TT>NoPaginate</TT></DT>
<DD>This exception can only be applied to the root element, i.e. the name that
appear after the keyword <TT>STRUCTURE</TT> at the beginning of the structure
schema. It indicates that the editor should not allow the user to paginate
documents of that type.
</DD>
<DT><TT>ParagraphBreak</TT></DT>
<DD>This exception can only be applied to element types. When the caret is
within an element of a type to which this exception is applied, it is that
element that will be split when the user hits the Return key.
</DD>
<DT><TT>HighlightChildren</TT></DT>
<DD>This exception can only be applied to element types. Elements of a type to
which this exception is applied are not highlighted themselves when they are
selected, but all their children are highlighted instead.
</DD>
<DT><TT>ExtendedSelection</TT></DT>
<DD>This exception can only be applied to element types. The selection
extension command (middle button of the mouse) only add the clicked element (if
it has that exception) to the current selection, without selecting other
elements between the current selection and the clicked element.
</DD>
</DL>
<BLOCKQUOTE class="example">
<P>
<STRONG>Example:</STRONG></P>
<P>
Consider a structure schema for object-style graphics which defines the
Graphic_object element type with the associated Height and Weight
numeric attributes. Suppose that we want documents of this class to have
the following qualities:</P>
<UL>
<LI>Whenever the width or height of an object is changed using the mouse, the
new values are stored in the object's Width and Height attributes.
<LI>The user should not be able to change the values of the Width and Height
attributes via the Attributes menu ofthe Thot editor.
</UL>
<P>
The following exceptions will produce this effect.</P>
<PRE>
STRUCT
...
Objet_graphique (ATTR Height = Integer; Width = Integer)
= GRAPHICS with Height ?= 10, Width ?= 10;
...
EXCEPT
Height: NewHeight, Invisible;
Width: NewWidth, Invisible;
</PRE>
</BLOCKQUOTE>
</DIV>
</DIV>
<DIV class="section">
<H2>Some examples</H2>
<P>
In order to illustrate the principles of the document model and the syntax of
the S language, this section presents two examples of structure schemas. One
defines a class of documents, the other defines a class of objects.</P>
<DIV class="subsection">
<H3>A class of documents: articles</H3>
<P>
This example shows a possible structure for articles published in a journal.
Text between braces is comments.</P>
<PRE>
STRUCTURE Article; { This schema defines the Article class }
DEFPRES ArticleP; { The default presentation schema is
ArticleP }
ATTR { Global attribute definitions }
WordType = Definition, IndexWord, DocumentTitle;
{ A single global attribute is defined, with three values }
STRUCT { Definition of the generic structure }
Article = BEGIN { The Article class has an aggregate
structure }
Title = BEGIN { The title is an aggregate }
French_title =
Text WITH Language='Fran\347ais';
English_title =
Text WITH Language='English';
END;
Authors =
LIST OF (Author
(ATTR Author_type=principal,secondary)
{ The Author type has a local attribute }
= BEGIN
Author_name = Text;
Info = Paragraphs ;
{ Paragraphs is defined later }
Address = Text;
END
);
Keywords = Text;
{ The journal's editor introduces the article
with a short introduction, in French and
in English }
Introduction =
BEGIN
French_intr = Paragraphs WITH
Language='Fran\347ais';
English_intr = Paragraphs WITH
Language='English';
END;
Body = Sections; { Sections are defined later }
{ Appendixes are only created on demand }
? Appendices =
LIST OF (Appendix =
BEGIN
Appendix_Title = Text;
Appendix_Contents = Paragraphs;
END
);
END; { End of the Article aggregate }
Sections = LIST [2..*] OF (
Section = { At least 2 sections }
BEGIN
Section_title = Text;
Section_contents =
BEGIN
Paragraphs;
Sections; { Sections at a lower level }
END;
END
);
Paragraphs = LIST OF (Paragraph = CASE OF
Enumeration =
LIST [2..*] OF
(Item = Paragraphs);
Isolated_formula = Formula;
LIST OF (UNIT);
END
);
ASSOC { Associated elements definitions }
Figure = BEGIN
Figure_legend = Text;
Illustration = NATURE;
END;
Biblio_citation = CASE OF
Ref_Article =
BEGIN
Authors_Bib = Text;
Article_Title = Text;
Journal = Text;
Page_Numbers = Text;
Date = Text;
END;
Ref_Livre =
BEGIN
Authors_Bib; { Defined above }
Book_Title = Text;
Editor = Text;
Date; { Defined above }
END;
END;
Note = Paragraphs - (Ref_note);
UNITS { Elements which can be used in objects }
Ref_note = REFERENCE (Note);
Ref_biblio = REFERENCE (Biblio_citation);
Ref_figure = REFERENCE (Figure);
Ref_formula = REFERENCE (Isolated_formula);
EXPORT { Skeleton elements }
Title,
Figure with Figure_legend,
Section With Section_title;
END { End of the structure schema }
</PRE>
<P>
This schema is very complete since it defines both paragraphs and
bibliographic citations. These element types could just as well be defined in
other structure schemas, as is the case with the <TT>Formula</TT> class. All
sorts of other elements can be inserted into an article, since a paragraph can
contain any type of unit. Similarly, figures can be any class of document or
object that the user chooses.</P>
<P>
Generally, an article doesn't contain appendices, but it is possible to add
them on explicit request: this is the effect of the question mark before the
word Appendices.</P>
<P>
The Figure, Biblio_citation and Note elements are associated elements. Thus,
they are only used in <TT>REFERENCE</TT> statements.</P>
<P>
Various types of cross-references can be put in paragraphs. They can also be
placed the objects which are part of the article, since the cross-references
are defined as units (<TT>UNITS</TT>).</P>
<P>
There is a single restriction to prevent the creation of Ref_note elements
within notes.</P>
<P>
It is worth noting that the S language permits the definition of recursive
structures like sections: a section can contain other sections (which are thus
at the next lower level of the document tree). Paragraphs are also recursive
elements, since a paragraph can contain an enumeration in which each element
(<TT>Item</TT>) is composed of paragraphs.</P>
</DIV>
<DIV class="subsection">
<H3>A class of objects: mathematical formulas</H3>
<P>
The example below defines the <TT>Formula</TT> class which is used in Article
documents. This class represents mathematical formulas with a rather simple
structure, but sufficient to produce a correct rendition on the screen or
printer. To support more elaborate operations (formal or numeric
calculations), a finer structure should be defined. This class doesn't use any
other class and doesn't define any associated elements or units.</P>
<PRE>
STRUCTURE Formula;
DEFPRES FormulaP;
ATTR
String_type = Function_name, Variable_name;
STRUCT
Formula = Expression;
Expression = LIST OF (Construction);
Construction = CASE OF
TEXT; { Simple character string }
Index = Expression;
Exponent = Expression;
Fraction =
BEGIN
Numerator = Expression;
Denominator = Expression;
END;
Root =
BEGIN
? Order = TEXT;
Root_Contents = Expression;
END;
Integral =
BEGIN
Integration_Symbol = SYMBOL;
Lower_Bound = Expression;
Upper_Bound = Expression;
END;
Triple =
BEGIN
Princ_Expression = Expression;
Lower_Expression = Expression;
Upper_Expression = Expression;
END;
Column = LIST [2..*] OF
(Element = Expression);
Parentheses_Block =
BEGIN
Opening = SYMBOL;
Contents = Expression;
Closing = SYMBOL;
END;
END; { End of Choice Constructor }
END { End of Structure Schema }
</PRE>
<P>
This schema defines a single global attribute which allows functions and
variables to be distinguished. In the presentation schema, this attribute can
be used to choose between roman (for functions) and italic characters (for
variables).</P>
<P>
A formula's structure is that of a mathematical expression, which is itself a
sequence of mathematical constructions. A mathematical construction can be
either a simple character string, an index, an exponent, a fraction, a root,
etc. Each of these mathematical constructions has a sensible structure which
generally includes one or more expressions, thus making the formula class's
structure definition recursive.</P>
<P>
In most cases, the roots which appear in the formulas are square roots and
their order (2) is not specified. This is why the Order component is marked
optional by a question mark. When explicitly requested, it is possible to add
an order to a root, for example for cube roots (order = 3).</P>
<P>
An integral is formed by an integration symbol, chosen by the user (simple
integral, double, curvilinear, etc.), and two bounds. A more fine-grained
schema would add components for the integrand and the integration variable.
Similarly, the Block_Parentheses construction leaves the choice of opening and
closing symbols to the user. They can be brackets, braces, parentheses,
etc.</P>
</DIV>
</DIV>
<HR>
</DIV>
<DIV class="chapter">
<H1>The P Language</H1>
<DIV class="section">
<H2>Document presentation</H2>
<P>
Because of the model adopted for Thot, the presentation of documents is
clearly separated from their structure and content. After having presented
the logical structure of documents, we now detail the principles implemented
for their presentation. The concept of <EM>presentation</EM> encompasses what
typographers call the page layout, the composition, and the model of the
document. It is the set of operations which display the document on the
screen or print it on paper. Like logical structure, document presentation is
defined generically with the help of a language, called P.</P>
<DIV class="subsection">
<H3>Two levels of presentation</H3>
<P>
The link between structure and presentation is clear: the logical organization
of a document is used to carry out its presentation, since the purpose of the
presentation is to make evident the organization of the document. But the
presentation is equally dependent on the device used to render the document.
Certain presentation effects, notably changes of font or character set, cannot
be performed on all printers or on all screens. This is why Thot uses a
two-level approach, where the presentation is first described in abstract
terms, without taking into account each particular device, and then the
presentation is realized within the constraints of a given device.</P>
<P>
Thus, presentation is only described as a function of the structure of the
documents and the image that would be produced on an idealized device. For
this reason, presentation descriptions do not refer to any device
characteristics: they describe <EM>abstract presentations</EM> which can be
concretized on different devices.</P>
<P>
A presentation description also defines a <EM>generic presentation</EM>, since
it describes the appearance of a class of documents or objects. This generic
presentation must also be applied to document and object instances, each
conforming to its generic logical structure, but with all the allowances that
were called to mind above: missing elements, constructed elements with other
logical structures, etc.</P>
<P>
In order to preserve the homogeneity between documents and objects,
presentation is described with a single set of tools which support the layout
of a large document as well as the composition of objects like a graphical
figure or mathematical formula. This unity of presentation description tools
contrasts with the traditional approach, which focuses more on documents than
objects and thus is based on the usual typographic conventions, such as the
placement of margins, indentations, vertical spaces, line lengths,
justification, font changes, etc.</P>
</DIV>
<DIV class="subsection">
<H3>Boxes</H3>
<P>
To assure the homogeneity of tools, all presentation in Thot, for documents as
well as for the objects which they contain, is based on the notion of the
<EM>box</EM>, such as was implemented in T<SUB><BIG>E</BIG></SUB>X.</P>
<P>
Corresponding to each element of the document is a box, which is the
rectangle enclosing the element on the display device (screen or sheet of
paper); the outline of this rectangle is normally not visible. The sides of
the box are parallel to the sides of the screen or the sheet of paper. By way
of example, a box is associated with a character string, a line of text, a
page, a paragraph, a title, a mathematical formula, or a table cell.</P>
<P>
Whatever element it corresponds to, each box possesses four sides and four
axes, which we designate as follows (<A href="#boxes">see figure</A>):</P>
<DL>
<DT><TT> Top</TT></DT>
<DD>the upper side,
</DD>
<DT><TT> Bottom</TT></DT>
<DD>the lower side,
</DD>
<DT><TT> Left</TT></DT>
<DD>the left side,
</DD>
<DT><TT> Right</TT></DT>
<DD>the right side,
</DD>
<DT><TT> VMiddle</TT></DT>
<DD>the vertical axis passing through the center of the box,
</DD>
<DT><TT> HMiddle</TT></DT>
<DD>the horizontal axis passing through the center of the box,
</DD>
<DT><TT> VRef</TT></DT>
<DD>the vertical reference axis,
</DD>
<DT><TT> HRef</TT></DT>
<DD>the horizontal reference axis.
</DD>
</DL>
<DIV class="figure">
<HR>
<PRE>
Left VRef VMiddle Right
: :
Top -----------------------------
| : : |
| : : |
| : : |
| : : |
| : : |
HMiddle ..|...........................|..
| : : |
| : : |
HRef ..|...........................|..
| : : |
| : : |
Bottom -----------------------------
: :
</PRE>
<P align=center>
<EM><A name="boxes">The sides and axes of boxes</A><EM></EM></EM></P>
<HR>
</DIV>
<P>
The principal role of boxes is to set the extent and position of the images of
the different elements of a document with respect to each other on the
reproduction device. This is done by defining relations between the boxes of
different elements which give relative extents and positions to these
boxes.</P>
<P>
There are three types of boxes:</P>
<UL>
<LI>boxes corresponding to structural elements of the document,
<LI>presentation boxes,
<LI>page layout boxes.
</UL>
<P>
<STRONG>Boxes corresponding to structural elements of the document</STRONG>
are those which linked to each of the elements (base or structured) of the
logical structure of the document. Such a box contains all the contents of
the element to which it corresponds (there is an exception: see rules
<TT>VertOverflow</TT> and <TT>HorizOverflow</TT>). These boxes form a
tree-like structure, identical to that of the structural elements to which
they correspond. This tree expresses the inclusion relationships between the
boxes: a box includes all the boxes of its subtree. On the other hand, there
are no predefined rules for the relative positions of the included boxes. If
they are at the same level, they can overlap, be contiguous, or be disjoint.
The rules expressed in the generic presentation specify their relative
positions.</P>
<P>
<STRONG>Presentation boxes</STRONG> represent elements which are not found in
the logical structure of the document but which are added to meet the needs of
presentation. These boxes are linked to the elements of the logical structure
that are best suited to bringing them out. For example, they are used to add
the character string ``Summary:'' before the summary in the presentation of a
report or to represent the fraction bar in a formula, or also to make the
title of a field in a form appear. These elements have no role in the logical
structure of the document: the presence of a Summary element in the document
does not require the creation of another structural object to hold the word
``Summary''. Similarly, if a Fraction element contains both a Numerator
element and a Denominator element, the fraction bar has no purpose
structurally. On the other hand, these elements of the presentation are
important for the reader of the reproduced document or for the user of an
editor. This is why they must appear in the document's image. It is the
generic presentation which specifies the presentation boxes to add by
indicating their content (a base element for which the value is specified) and
the position that they must take in the tree of boxes. During editing, these
boxes cannot be modified by the user.</P>
<P>
<STRONG>Page layout boxes</STRONG> are boxes created implicitly by the page
layout rules. These rules indicate how the contents of a structured element
must be broken into lines and pages. In contrast to presentation boxes, these
line and page boxes do not depend on the logical structure of the document,
but rather on the physical constraints of the reproduction services: character
size, height and width of the window on the screen or of the sheet of
paper.</P>
</DIV>
<DIV class="subsection">
<H3>Views and visibility</H3>
<P>
One of the operations that one might wish to perform on a document is to view
it is different ways. For this reason, it is possible to define several
<EM>views</EM> for the same document, or better yet, for all documents of the
same class. A view is not a different presentation of the document, but
rather a filter which only allows the display of certain parts of the
document. For example, it might be desirable to see only the titles of
chapters and sections in order to be able to move rapidly through the
document. Such a view could be called a ``table of contents''. It might also
be desirable to see only the mathematical formulas of a document in order to
avoid being distracted by the non-mathematical aspects of the document. A
``mathematics'' view could provide this service.</P>
<P>
Views, like presentation, are based on the generic logical structure. Each
document class, and each generic presentation, can be provided with views
which are particularly useful for that class or presentation. For each view,
the <EM>visibility</EM> of elements is defined, indicated whether or not the
elements must be presented to the user. The visibility is calculated as a
function of the type of the elements or their hierarchical position in the
structure of the document. Thus, for a table of contents, all the ``Chapter
Title'' and ``Section Title'' elements are made visible. However, the
hierarchical level could be used to make the section titles invisible below a
certain threshold level. By varying this threshold, the granularity of the
view can be varied. In the ``mathematics'' view, only Formula elements would
be made visible, no matter what their hierarchical level.</P>
<P>
Because views are especially useful for producing a synthetic image of the
document, it is necessary to adapt the presentation of the elements to the
view in which they appear. For example, it is inappropriate to have a page
break before every chapter title in the table of contents. Thus, generic
presentations take into account the possible views and permit each element
type's presentation to vary according the view in which its image appears.</P>
<P>
<A name="views">Views</A> are also used, when editing documents, to display
the associated elements. So, in addition to the primary view of the document,
there can be a ``notes'' view and a ``figures'' view which contain,
respectively, the associated elements of the Note and Figure types. In this
way, it is possible to see simultaneously the text which refers to these
elements and the elements themselves, even if they will be separated when
printed.</P>
</DIV>
<DIV class="subsection">
<H3>Pages</H3>
<P>
Presentation schemas can be defined which display the document as a long
scroll, without page breaks. This type of schema is particularly well-suited
to the initial phase of work on a document, where jumps from page to page
would hinder composing and reading the document on a screen. In this case,
the associated elements (such as notes), which are normally displayed in the
page footer, are presented in a separate window. But, once the document is
written, it may be desirable to display the document on the screen in the same
manner in which it will be printed. So, the presentation schema must define
pages.</P>
<P>
The P language permits the specification of the dimensions of pages as well as
their composition. It is possible to generate running titles, page numbers,
zones at the bottom of the page for notes, etc. The editor follows this model
and inserts page break marks in the document which are used during printing,
insuring that the pages on paper are the same as on the screen.</P>
<P>
Once a document has been edited with a presentation schema defining pages, it
contains page marks. But it is always possible to edit the document using a
schema without pages. In this case, the page marks are simply ignored by the
editor. They are considered again as soon as a schema with pages is used.
Thus, the user is free to choose between schemas with and without pages.</P>
<P>
Thot treats the page break, rather than the page itself, as a box. This page
break box contains all the elements of one page's footer, a rule marking the
edge of this page, and all the elements of the next page's header. The
elements of the header and footer can be running titles, page number,
associated elements (notes, for example), etc. All these elements, as well as
their content and graphical appearance, are defined by the generic
presentation.</P>
</DIV>
<DIV class="subsection">
<H3>Numbering</H3>
<P>
Many elements are numbered in documents: pages, chapters, sections, formulas,
theorems, notes, figures, bibliographic references, exercises, examples,
lemmas, etc. Because Thot has a notion of logical structure, all of these
numbers (with the exception of pages) are redundant with information implicit
in the logical structure of the document. Such numbers are simply a way to
make the structure of the document more visible. So, they are part of the
document's presentation and are calculated by the editor from the logical
structure. The structure does not contain numbers as such; it only defines
relative structural positions between elements, which serve as ordering
relations on these elements.</P>
<P>
If the structure schema defines the body of a document as a sequence of at
least two chapters:</P>
<PRE>
Body = LIST [2..*] OF Chapter ;
</PRE>
<P>
the sequence defined by the list constructor is ordered and eachchapter can be
assigned a number based on its rank in the Body list.Therefore, all elements
contained in lists a the structure of adocument can be numbered, but they are
not the only ones. The treestructure induced by the aggregate, list, and
choice constructors(excluding references) defines a total order on the
elements of thedocument's primary structure. So, it is possible to define
anumbering which uses this order, filtering elements according to theirtype so
that only certain element types are taken into account in thenumbering. In
this way, it possible to number all the theorems andlemmas of a chapter in the
same sequence of numbers, even when theyare not part of the same list
constructor and appear at differentlevels of the document's tree. By changing
the filter, they can benumbered separately: one sequence of numbers for
theorems, another forthe lemmas.</P>
<P>
Associated elements pose a special problem, since they are not part of the
document's primary structure, but are attached only by references, which
violate the total order of the document. Then, these associated elements are
frequently numbered, precisely because the number is an effective way to
visualize the reference. In order to resolve this problem, Thot implicitly
defines a list constructor for each type of associated element, gathering
together (and ordering) these elements. Thus, the associated elements can be
numbered by type.</P>
<P>
Since they are calculated from the document's logical structure and only for
the needs of the presentation, numbers are presentation elements, described by
presentation boxes, just like the fraction bar or the word ``Summary''.
Nevertheless, numbers differ from these other boxes because their content
varies from instance to instance, even though they are of the same type,
whereas all fraction bars are horizontal lines and the same word ``Summary''
appears at the head of every document's summary.</P>
</DIV>
<DIV class="subsection">
<H3>Presentation parameters</H3>
<P>
The principal parameters which determine document presentation are the
<EM>positions</EM> and <EM>dimensions</EM> of boxes, the <EM>font</EM>, the
<EM>style</EM>, the <EM>size</EM>, the <EM>underlining</EM> and the
<EM>color</EM> of their content. From these parameters, and some others of
less importance, it is possible to represent the usual typographic parameters
for the textual parts of the document. These same parameters can be used to
describe the geometry of the non-textual elements, even though they are
two-dimensional elements unlike the text, which is linear.</P>
<P>
As we have already seen, the positions of the boxes always respect the rule
of enclosure: a box in the tree encloses all the boxes of the next lower level
which are attached to it. The positional parameters permit the specification
of the position of each box in relation to the enclosing box or to its sibling
boxes (boxes directly attached to the same enclosing box in the tree of
boxes).</P>
<P>
The presentation parameters also provide control over the dimensions of the
boxes. The dimensions of a box can depend either on its content or on its
context (its sibling boxes and the enclosing box). Each dimension (height or
width) can be defined independently of the other.</P>
<P>
Because of the position and dimension parameters, it is possible to do the
same things that are normally done in typography by changing margins, line
lengths, and vertical or horizontal skips. This approach can also align or
center elements and groups of elements.</P>
<P>
In contrast to the position and dimension parameters, the font, style, size,
underlining, and color do not concern the box itself (the rectangle delimiting
the element), but its content. These parameters indicate the typographic
attributes which must be applied to the text contained in the box, and by
extension, to all base elements.</P>
<P>
For text, the font parameter is used to change the family of characters
(Times, Helvetica, Courier, etc.); the style is used to obtain italic or
roman, bold or light characters; the size determines the point size of the
characters; underlining defines the type and thickness of the lines drawn
above, below, or through the characters.</P>
<P>
For graphics, the line style parameter can be either solid, dotted, or dashed;
the line thickness parameter controls the width of the lines; the fill pattern
parameter determines how closed geometric figures must be filled.</P>
<P>
While some of the parameters which determine the appearance of a box's
contents make sense only for one content type (text or graphic), other
parameters apply to all content types: these are the color parameters. These
indicate the color of lines and the background color.</P>
</DIV>
</DIV>
<DIV class="section">
<H2><A name="langp">Presentation description language</A></H2>
<P>
A generic presentation defines the values of presentation parameters (or the
way to calculate those values) for a generic structure, or more precisely, for
all the element types and all the global and local attributes defined in that
generic structure. This definition of the presentation parameters is made
with the P language. A program written in this language, that is a generic
presentation expressed in P, is call a <EM>presentation schema</EM>. This
section describes the syntax and semantics of the language, using the same <A
href="#metalang">meta-language</A> as was used for the definition of the S
language.</P>
<P>
Recall that it is possible to write many different presentation schemas for
the same class of documents or objects. This allows users to choose for a
document the graphical appearance which best suits their type of work or
their personal taste.</P>
<DIV class="subsection">
<H3>The organization of a presentation schema</H3>
<P>
A presentation schema begins with the word <TT>PRESENTATION</TT> and ends with
the word <TT>END</TT>. The word <TT>PRESENTATION</TT> is followed by the name
of the generic structure to which the presentation will be applied. This name
must be the same as that which follows the keyword <TT>STRUCTURE</TT> in the
structure schema associated with the presentation schema.</P>
<P>
After this declaration of the name of the structure, the following sections
appear (in order):</P>
<UL>
<LI>Declarations of
<UL>
<LI>all views,
<LI>printed views,
<LI>counters,
<LI>presentation constants,
<LI>variables,
</UL>
<LI>default presentation rules,
<LI>presentation box and page layout box definitions,
<LI>presentation rules for structured elements,
<LI>presentation rules for attributes,
<LI>rules for transmitting values to attributes of included documents.
</UL>
<P>
Each of these sections is introduced by a keyword which is followed by a
sequence of declarations. Every section is optional.</P>
<PRE>
SchemaPres ='PRESENTATION' ElemID ';'
[ 'VIEWS' ViewSeq ]
[ 'PRINT' PrintViewSeq ]
[ 'COUNTERS' CounterSeq ]
[ 'CONST' ConstSeq ]
[ 'VAR' VarSeq ]
[ 'DEFAULT' ViewRuleSeq ]
[ 'BOXES' BoxSeq ]
[ 'RULES' PresentSeq ]
[ 'ATTRIBUTES' PresAttrSeq ]
[ 'TRANSMIT' TransmitSeq ]
'END' .
ElemID = NAME .
</PRE>
</DIV>
<DIV class="subsection">
<H3>Views</H3>
<P>
Each of the possible views must be declared in the presentation schema. As
has <A href="#views">already been described</A>, the presentation rules for an
element type can vary according to the view in which the element appears. The
name of the view is used to designate the view to which the presentation rules
apply (see the <A href="#inkeyword"><TT>IN</TT> instruction</A>). The
definition of the view's contents are dispersed throughout the presentation
rules attached to the different element types and attributes. The
<TT>VIEWS</TT> section is simply a sequence of view names separated by commas
and terminated by a semi-colon.</P>
<P>
One of the view names (and only one) can be followed by the keyword
<TT>EXPORT</TT>. This keyword identifies the view which presents the members
of the document class in <A href="#skeleton">skeleton form</A>. The graphical
appearance and the content of this view is defined just as with other views,
but it is useless to specify presentation rules concerning this view for the
elements which are not loaded in the skeleton form.</P>
<P>
It is not necessary to declare any views; in this case there is a single
unnamed view. If many views are declared, the first view listed is considered
the principal view. The principal view is the one to which all rules that are
not preceded by an indication of a view will apply (see the <A
href="#inkeyword">instruction <TT>IN</TT></A>).</P>
<P>
The principal view is the the one which the editor presents on the screen when
the user asks to create or edit a document. Thus, it makes sense to put the
most frequently used view at the head of the list. But if the structure
schema contains <A href="#skeleton">skeleton elements</A> and is loaded in its
skeleton form, the view whose name is followed by the keyword <TT>EXPORT</TT>
will be opened and no other views can be opened.</P>
<PRE>
'VIEWS' ViewSeq
ViewSeq = ViewDeclaration
< ',' ViewDeclaration > ';' .
ViewDeclaration = ViewID [ 'EXPORT' ] .
ViewID = NAME .
</PRE>
<BLOCKQUOTE class="example">
<P>
<STRONG>Example:</STRONG></P>
<P>
When editing a report, it might be useful have views of the table of contents
and of the mathematical formulas, in addition to the principal view which shows
the document in its entirety. To achieve this, a presentation schema for the
Report class would have the following <TT>VIEWS</TT> section:</P>
<PRE>
VIEWS
Full_text, Table_of_contents, Formulas;
</PRE>
<P>
The contents of these views are specified in the presentation rules of the
schema.</P>
</BLOCKQUOTE>
</DIV>
<DIV class="subsection">
<H3>Print Views</H3>
<P>
When editing a document, each view is presented in a different window. In
addition to the views specified by the <TT>VIEWS</TT> instruction, the user
can display the associated elements with one window for each type of
associated element.</P>
<P>
When printing a document, it is possible to print any number of views, chosen
from among all the views which the editor can display (views in the strict
sense or associated elements). Print views, as well as the order in which
they must be printed, are indicated by the <TT>PRINT</TT> instruction. It
appears after the <TT>VIEWS</TT> instruction and is formed of the keyword
<TT>PRINT</TT> followed by the ordered list of print view names. The print
view names are separated by commas and followed by a semi-colon. A print view
name is either a view name declared in the <TT>VIEWS</TT> instruction or the
name of an associated element type (with an ``s'' added to the end). The
associated element must have been declared in the <TT>ASSOC</TT> section of
the structure schema.</P>
<PRE>
'PRINT' PrintViewSeq
PrintViewSeq = PrintView < ',' PrintView > ';' .
PrintView = ViewID / ElemID .
</PRE>
<P>
If the <TT>PRINT</TT> instruction is absent, the printing program will print
only the principal view (the first view specified by the <TT>VIEWS</TT>
instruction or the single, unnamed view when there is no <TT>VIEWS</TT>
instruction).</P>
<BLOCKQUOTE class="example">
<P>
<STRONG>Example:</STRONG></P>
<P>
Consider a Report presentation using the view declarations from the preceding
example. Suppose we want to print the full text and table of contents views,
but not the Formulas view, which is only useful when editing. In addition,
suppose that we also want to print the bibliographic citations, which are
associated elements (of type <TT>Citation</TT>). A sensible printing order
would be to print the full text then the bibliography and finally the table of
contents. To obtain this result when printing, the presentation schema would
say:</P>
<PRE>
PRINT
Full_text, Citations, Table_of_contents;
</PRE>
</BLOCKQUOTE>
</DIV>
<DIV class="subsection">
<H3>Counters</H3>
<P>
A presentation has a <EM>counter</EM> for each type of number in the
presentation. All counters, and therefore all types of numbers, used in the
schema must be declared after the <TT>COUNTERS</TT> keyword.</P>
<P>
Each counter declaration is composed of a name identifying the counter
followed by a colon and the counting function to be applied to the counter.
The counter declaration ends with a semi-colon.</P>
<P>
The counting function indicates how the counter values will be calculated.
Three types of counting functions are available. The first type is used to
count the elements of a list or aggregate: it assigns to the counter the rank
of the element in the list or aggregate. More precisely, the function</P>
<PRE>
RANK OF ElemID [ LevelAsc ] [ INIT AttrID ]
[ 'REINIT' AttrID ]
</PRE>
<P>
indicates that when an element creates, by a creation rule (see the<A
href="#creation"><TT>Create</TT> instructions</A>), a presentationbox
containing the counter value, this value is the rank of thecreating element,
if it is of type <TT>ElemID</TT>, otherwise the rank ofthe first element of
type <TT>ElemID</TT>which encloses the creatingelement in the logical
structure of the document.</P>
<P>
The type name can be preceded by a star in the special case where the
structure schema defines an element of whose <TT>ElemID</TT> is the same as
that of an <A href="#references">inclusion</A> without expansion or with
partial expansion. To resolve this ambiguity, the <TT>ElemID</TT> alone
refers to the type defined in the structure schema while the <TT>ElemID</TT>
preceded by a star refers to the included type.</P>
<P>
The type name <TT>ElemID</TT> can be followed by an integer. That number
represents the relative level, among the ancestors of the creating element, of
the element whose rank is asked. If that relative level <I>n</I> is unsigned,
the <I>n</I><SUP>th</SUP> element of type <TT>ElemID</TT> encountered when
travelling the logical structure from the root to the creating element is
taken into account. If the relative level is negative, the logical structure
is travelled in the other direction, from the creating element to the
root.</P>
<P>
The function can end with the keyword <TT>INIT</TT> followed by the name of a
numeric attribute (and only a numeric attribute). Then, the rank of the first
element of the list or aggregate is considered to be the value of this
attribute, rather than the default value of 1, and the rank of the other
elements is shifted accordingly. The attribute which determines the initial
value is searched on the element itself and on its ancestors.</P>
<P>
The function can end with the keyword <TT>REINIT</TT> followed by the name of
a numeric attribute (and only a numeric attribute). Then, if an element to be
counted has this attribute, the counter value for this element is the
attribute value and the following elements are numbered starting from this
value.</P>
<P>
When the <TT>RANK</TT> function is written</P>
<PRE>
RANK OF Page [ ViewID ] [ INIT AttrID ]
</PRE>
<P>
(<TT>Page</TT>is a keyword of the P language), the counter takes as itsvalue
the number of the page on which the element which creates thepresentation box
containing the number appears. This is done as ifthe pages of the document
form a list for each view. The counter onlytakes into account the pages of
the relevant view, that is the viewdisplaying the presentation box whose
contents take the value of thenumber. However, if the keyword <TT>Page</TT>is
followed by the name of aview (between parentheses), it is the pages of that
view that aretaken into account. As in the preceding form, the
<TT>RANK</TT>functionapplied to pages can end with the <TT>INIT</TT>keyword
followed the nameof a numeric attribute which sets the value of the first
page'snumber. This attribute must be a local attribute of the documentitself,
and not of one of its components.</P>
<P>
The second counting function is used to count the occurrences of a certain
element type in a specified context. The instruction</P>
<PRE>
SET n ON Type1 ADD m ON Type2 [ INIT AttrID ]
</PRE>
<P>
says that when the document is traversed from beginning to end (in theorder
induced by the logical structure), the counter is assigned thevalue
<TT>n</TT>each time an element of type <TT>Type1</TT>is encountered, nomatter
what the current value of the counter, and the value <TT>m</TT>isadded to the
current value of the counter each time an element of type<TT>Type2</TT>is
encountered.</P>
<P>
As with the <TT>RANK</TT> function, the type names can be preceded by a star
to resolve the ambiguity of included elements.</P>
<P>
If the function ends with the keyword <TT>INIT</TT> followed by the name of an
attribute and if the document possesses this attribute, the value of this
attribute is used in place of <TT>n</TT>. The attribute must be numeric. It
is searched on the element itself and on its ancestors.</P>
<P>
This function can also be used with the <TT>Page</TT> keyword in the place of
<TT>Type1</TT> or <TT>Type2</TT>. In the first case, the counter is
reinitialized on each page with the value <TT>n</TT>, while in the second
case, it is incremented by <TT>m</TT> on each page. As with the preceding
counting function, the word <TT>Page</TT> can be followed by a name between
parentheses. In this case, the name specifies a view whose pages are taken
into account.</P>
<P>
The definition of a counter can contain several <TT>SET</TT> functions and
several <TT>ADD</TT> functions, each with a different value. The total number
of counting functions must not be greater than 6.</P>
<P>
The third counting function is used to count the elements of a certain type
encountered when travelling from the creating element to the root of the
logical structure. The creating element is included if it is of that type.
That function is written</P>
<PRE>
RLEVEL OF Type
</PRE>
<P>
where <TT>Type</TT>represents the type of the elements to be counted.</P>
<P>
The formal definition of counter declarations is:</P>
<PRE>
'COUNTERS' CounterSeq
CounterSeq = Counter < Counter > .
Counter = CounterID ':' CounterFunc ';' .
CounterID = NAME .
CounterFunc = 'RANK' 'OF' TypeOrPage [ SLevelAsc ]
[ 'INIT' AttrID ] [ 'REINIT' AttrID ] /
SetFunction < SetFunction >
AddFunction < AddFunction >
[ 'INIT' AttrID ] /
'RLEVEL' 'OF' ElemID .
SLevelAsc = [ '-' ] LevelAsc .
LevelAsc = NUMBER .
SetFunction = 'SET' CounterValue 'ON' TypeOrPage .
AddFunction = 'ADD' CounterValue 'ON' TypeOrPage .
TypeOrPage = 'Page' [ '(' ViewID ')' ] /
[ '*' ] ElemID .
CounterValue = NUMBER .
</PRE>
<BLOCKQUOTE class="example">
<P>
<STRONG>Example:</STRONG></P>
<P>
If the body of a chapter is defined as a sequence of sections in the structure
schema:</P>
<PRE>
Chapter_body = LIST OF (Section =
BEGIN
Section_Title = Text;
Section_Body = Paragraphs;
END
);
</PRE>
<P>
the section counter is declared:</P>
<PRE>
SectionCtr : RANK OF Section;
</PRE>
<P>
and the display of the section number before the section title isobtained by a
<A href="#creation"><TT>CreateBefore</TT> rule</A>attached the
<TT>Section_Title</TT>type, which creates a presentationbox whose content is
the value of the <TT>SectionCtr</TT>counter (seethe <A
href="#content"><TT>Content</TT> instruction</A>).</P>
<P>
In order to number the formulas separately within each chapter, the formula
counter is declared:</P>
<PRE>
FormulaCtr : SET 0 ON Chapter ADD 1 ON Formula;
</PRE>
<P>
and the display of the formula number in the right margin, alongsideeach
formula, is obtained by a <TT>CreateAfter</TT>instruction attachedto the
<TT>Formula</TT>type, which creates a presentation box whosecontent is the
value of the <TT>FormulaCtr</TT>counter.</P>
<P>
To number the page chapter by chapter, with the first page of each chapter
having the number 1, the counter definition would be</P>
<PRE>
ChapterPageCtr : SET 0 ON Chapter ADD 1 ON Page;
</PRE>
<P>
If there is also a chapter counter</P>
<PRE>
ChapterCtr : RANK OF Chapter;
</PRE>
<P>
the <A href="#content">content</A>of a presentation box createdat the top of
each page could be defined as:</P>
<PRE>
Content : (VALUE(ChapterCtr, URoman) TEXT '-'
VALUE(ChapterPageCtr, Arabic));
</PRE>
<P>
Thus, the presentation box contains the number of the chapter inupper-case
romannumerals followed by a hyphen and the number of the page within
thechapter in arabic numerals.</P>
</BLOCKQUOTE>
<BLOCKQUOTE class="example">
<P>
<STRONG>Example:</STRONG></P>
<P>
To count tables and figures together in a document of the chapter type, a
counter could be defined using:</P>
<PRE>
CommonCtr : SET 0 ON Chapter ADD 1 ON Table
ADD 1 ON Figure;
</PRE>
</BLOCKQUOTE>
</DIV>
<DIV class="subsection">
<H3><A name="presconst">Presentation constants</A></H3>
<P>
Presentation constants are used in the definition of the content of
presentation boxes. This content is used in <A href="#variables">variable
definitions</A> and in the <A href="#content"><TT>Content</TT> rule</A>. The
only presentation constants which can be used are character strings,
mathematical symbols, graphical elements, and pictures, that is to say, base
elements.</P>
<P>
Constants can be defined directly in the variables or presentation boxes
(<TT>Content</TT> rule) which use them. But it is only necessary them to
declare once, in the constant declaration section, even though they are used
in many variables or boxes. Thus, each declared constant has a name, which
allows it to be designated whenever it is used, a type (one of the four base
types) and a value (a character string or a single character for mathematical
symbols and graphical elements).</P>
<P>
The constant declarations appear after the keyword <TT>CONST</TT>. Each
declaration is composed of the name of the constant, an equals sign, a keyword
representing its type (<TT>Text</TT>, <TT>Symbol</TT>, <TT>Graphics</TT> or
<TT>Picture</TT>) and the string representing its value. A semi-colon
terminates each declaration.</P>
<P>
In the case of a character string, the keyword <TT>Text</TT> can be followed
by the name of an alphabet (for example, <TT>Greek</TT> or <TT>Latin</TT>) in
which the constant's text should be expressed. If the alphabet name is
absent, the Latin alphabet is used. When the alphabet name is present, only
the first letter of the alphabet name is interpreted. Thus, the words
<TT>Greek</TT> and <TT>Grec</TT> designate the same alphabet. In current
versions of Thot, only the Greek and Latin alphabets are available.</P>
<PRE>
'CONST' ConstSeq
ConstSeq = Const < Const > .
Const = ConstID '=' ConstType ConstValue ';' .
ConstID = NAME .
ConstType ='Text' [ Alphabet ] / 'Symbol' /
'Graphics' / 'Picture' .
ConstValue = STRING .
Alphabet = NAME .
</PRE>
<P>
For character strings in the Latin alphabet (ISO-Latin 1 character set),
characters having codes higher than 127 (decimal) are represented by their
code in octal.</P>
<P>
In the case of a symbol or graphical element, the value only contains a single
character, between apostrophes, which indicates the form of the element which
must be drawn in the box whose content is the constant. The symbol or
graphical element takes the dimensions of the box, which are determined by the
<TT>Height</TT> and <TT>Width</TT> rules. See <A href="#symbolcoding">table of
codes</A> for the symbols and graphical elements.</P>
<BLOCKQUOTE class="example">
<P>
<STRONG>Example:</STRONG></P>
<P>
The constants ``Summary:'' and fraction bar, which were described earlier, are
declared:</P>
<PRE>
CONST
SummaryConst = Text 'Summary:';
Bar = Graphics 'h';
</PRE>
</BLOCKQUOTE>
</DIV>
<DIV class="subsection">
<H3><A name="variables">Variables</A></H3>
<P>
Variables permit the definition of computed content for presentation boxes. A
variable is associated with a presentation box by a <TT>Content</TT> rule; but
before being used in a <TT>Content</TT> rule, a variable can be defined in the
<TT>VAR</TT> section. It is also possible to define a variable at the time of
its use in a <TT>Content</TT> rule, as can be done with a constant.</P>
<P>
A variable has a name and a value which is a character string resulting from
the concatenation of the values of a sequence of functions. Each variable
declaration is composed of the variable name followed by a colon and the
sequence of functions which produces its value, separated by spaces. Each
declaration is terminated by a semi-colon.</P>
<PRE>
'VAR' VarSeq
VarSeq = Variable < Variable > .
Variable = VarID ':' FunctionSeq ';' .
VarID = NAME .
FunctionSeq = Function < Function > .
</PRE>
<P>
Several functions are available. The first two return, in the form of a
character string, the current date. <TT>DATE</TT> returns the date in
English, while <TT>FDATE</TT> returns the date in french.</P>
<P>
Two other functions, <TT>DocName</TT> and <TT>DirName</TT>, return the
document name and the directory where the document is stored.</P>
<P>
Function <TT>ElemName</TT> returns the type of the element which created the
presentation box whose contents are the variable.</P>
<P>
Another function simply returns the value of a presentation constant. For any
constant declared in the <TT>CONST</TT> section, it is sufficient to give the
name of the constant. Otherwise, the type and value of the constant must be
given, using the same form as in a <A href="#presconst">constant
declaration</A>. If the constant is not of type text, (types <TT>Symbol</TT>,
<TT>Graphics</TT> or <TT>Picture</TT>), it must be alone in the variable
definition; only constants of type <TT>Text</TT> can be mixed with other
functions.</P>
<P>
It is also possible to obtain the value of an attribute, simply by mentioning
the attribute's name. The value of this function is the value of the
attribute for the element which created the presentation box whose contents
are the variable. If the creating element does not have the indicated
attribute, the value is an empty string. In the case of a numeric attribute,
the attribute is translated into a decimal number in arabic numerals. If
another form is desired, the <TT>VALUE</TT> function must be used.</P>
<P>
The last available function returns, as a character string, the value of a
counter, an attribute or a page number. This value can be presented in
different styles. The keyword <TT>VALUE</TT> is followed (between
parentheses) by the name of the counter, the name of the attribute, or the
keyword <TT>PageNumber</TT> and the desired style, the two parameters being
separated by a comma. The style is a keyword which indicates whether the
value should be presented in arabic numerals (<TT>Arabic</TT>), lower-case
roman numerals (<TT>LRoman</TT>), or upper-case roman numerals
(<TT>URoman</TT>), or by an upper-case letter (<TT>Uppercase</TT>) or
lower-case letter (<TT>Lowercase</TT>).</P>
<P>
For a page counter, the keyword <TT>PageNumber</TT> can be followed, between
parentheses, by the name of the view from which to obtain the page number. By
default, the first view declared in the <TT>VIEWS</TT> section is used. The
value obtained is the number of the page on which is found the element that is
using the variable in a <TT>Content</TT> rule.</P>
<P>
For an ordinary counter, the name of the counter can be preceded by the
keyword <TT>MaxRangeVal</TT> or <TT>MinRangeVal</TT>. These keywords mean
that the value returned by the function is the maximum (minimum resp.) value
taken by the counter in the whole document, not the value for the element
concerned by the function.</P>
<PRE>
Function = 'DATE' / 'FDATE' /
'DocName' / 'DirName' /
'ElemName' / 'AttributeName' /
ConstID / ConstType ConstValue /
AttrID /
'VALUE' '(' PageAttrCtr ','
CounterStyle ')' .
PageAttrCtr = 'PageNumber' [ '(' ViewID ')' ] /
[ MinMax ] CounterID / AttrID .
CounterStyle = 'Arabic' / 'LRoman' / 'URoman' /
'Uppercase' / 'Lowercase' .
MinMax = 'MaxRangeVal' / 'MinRangeVal' .
</PRE>
<BLOCKQUOTE class="example">
<P>
<STRONG>Example:</STRONG></P>
<P>
To make today's date appear at the top of the first page of a report, a <A
href="#creation"><TT>CREATE</TT> rule</A> associated with the Report_Title
element type generates a presentation box whose content (specified by the
<TT>Content</TT> rule of that presentation box) is the variable:</P>
<PRE>
VAR
Todays_date : TEXT 'Version of ' DATE;
</PRE>
<P>
To produce, before each section title, the chapter number (in upper-case roman
numerals) followed by the section number (in arabic numerals), two counters
must be defined:</P>
<PRE>
COUNTERS
ChapterCtr : RANK OF Chapter;
SectionCtr : RANK OF Section;
</PRE>
<P>
and the Section_Title element must create a presentation box whosecontent is
the variable</P>
<PRE>
VAR
SectionNum : VALUE (ChapterCtr, URoman) TEXT '-'
VALUE (SectionCtr, Arabic);
</PRE>
<P>
In order to make the page number on which each section begins appear in the
table of contents view next to the section title, each Section_Title element
must create a presentation box, visible only in the table of contents view,
whose content is the variable:</P>
<PRE>
VAR
TitlePageNume :
VALUE (PageNumber(Full_text), Arabic);
</PRE>
</BLOCKQUOTE>
</DIV>
<DIV class="subsection">
<H3><A name="defaultpresrules">Default presentation rules</A></H3>
<P>
In order to avoid having to specify, for each element type defined in the
structure schema, values for every one of the numerous presentation
parameters, the presentation schema allows the definition of a set of default
presentation rules. These rules apply to all the boxes of the elements
defined in the structure schema and to the presentation boxes and page layout
boxes defined in the presentation schema. Only rules which differ from these
default need to be specified in other sections of the presentation schema.</P>
<P>
For the primary view, the default rules can define every presentation
parameter, but not the <A href="#presfunct">presentation functions</A> or the
<A href="#breakcond">linebreaking conditions</A> (the <TT>NoBreak1</TT>,
<TT>NoBreak2</TT>, and <TT>Gather</TT> rules).</P>
<P>
In a presentation schema, the default presentation rules section is optional;
in this case, the <TT>DEFAULT</TT> keyword is also absent and the following
rules are considered to be the default rules:</P>
<PRE>
Visibility: Enclosing =;
VertRef: * . Left;
HorizRef: Enclosed . HRef;
Height: Enclosed . Height;
Width: Enclosed . Width;
VertPos: Top = Previous . Bottom;
HorizPos: Left = Enclosing . Left;
VertOverflow: No;
HorizOverflow: No;
Size: Enclosing =;
Style: Enclosing =;
Font: Enclosing =;
Underline: Enclosing =;
Thickness: Enclosing =;
Indent: Enclosing =;
LineSpacing: Enclosing =;
Adjust: Enclosing =;
Justify: Enclosing =;
Hyphenate: Enclosing =;
PageBreak: Yes;
LineBreak: Yes;
InLine: Yes;
Depth: 0;
LineStyle: Enclosing =;
LineWeight: Enclosing =;
FillPattern: Enclosing =;
Background: Enclosing =;
Foreground: Enclosing =;
</PRE>
<P>
If other values are desired for the default rules, they must be defined
explicitly in the default rules section. In fact, it is only necessary to
define those default rules which differ from the ones above, since the rules
above will be used whenever a rule is not explicitly named.</P>
<P>
Default rules for views other than the primary view can also be specified.
Otherwise, the default rules for the primary views are applied to the other
views.</P>
<P>
Default rules are expressed in the same way as <A href="#presrule">explicit
rules for document elements</A>.</P>
</DIV>
<DIV class="subsection">
<H3>Presentation and page layout boxes</H3>
<P>
The presentation process uses elements which are not part of the logical
structure of the document, such as pages (which are the page layout boxes) or
alternatively, rules, numbers, or words introducing certain parts of the
document, such as ``Summary'', ``Appendices'', ``Bibliography'', etc. (which
are presentation boxes).</P>
<P>
After the word <TT>BOXES</TT>, each presentation or page layout box is defined
by its name and a sequence of presentation rules which indicate how they must
be displayed. These rules are the same as those which define the boxes
associated with element of the logical structure of the document, with a
single exception, the <A href="#content"><TT>Content</TT> rule</A> which is
used only to specify the content of presentation boxes. The content of boxes
associated with elements of the document structure is defined in each document
or object and thus is not specified in the presentation schema, which applies
to all documents or objects of a class.</P>
<P>
Among the rules which define a presentation box, certain ones can refer to
another presentation box (for example, in their positional rules). If the
designated box is defined after the box which designates it, a
<TT>FORWARD</TT> instruction followed by the name of the designated box must
appear before the designation.</P>
<PRE>
'BOXES' BoxSeq
BoxSeq = Box < Box > .
Box ='FORWARD' BoxID ';' /
BoxID ':' ViewRuleSeq .
BoxID = NAME .
</PRE>
</DIV>
<DIV class="subsection">
<H3>Presentation of structured elements</H3>
<P>
After the words <TT>RULES</TT>, the presentation schema gives the presentation
rules that apply to the elements whose types are defined in the structure
schema. Only those rules which differ from the <A
href="#defaultpresrules">default</A> must be specified in the <TT>RULES</TT>
section.</P>
<P>
The rule definitions for each element type are composed of the name of the
element type (as specified in the structure schema) followed by a colon and
the set of rules specific to that type.</P>
<P>
The type name can be preceded by a star in the special case where the
structure schema defines an <A href="#references">inclusion</A> without
expansion (or with partial expansion) of a type with the same name as an
element of defined in the structure schema.</P>
<P>
In the case where the element is a <A href="#pairs">mark pair</A>, but only in
this case, the type name can be preceded by the keywords <TT>First</TT> or
<TT>Second</TT>. These keywords indicate whether the rules that follow apply
to the first or second mark of the pair.</P>
<PRE>
'RULES' PresentSeq
PresentSeq = Present < Present > .
Present = [ '*' ] [ FirstSec ] ElemID ':'
ViewRuleSeq .
FirstSec = 'First' / 'Second' .
</PRE>
<P>
A presentation schema can define presentation rules for base elements, which
are defined implicitly in the structure schemas. In the English version of
the presentation schema compiler, the base type names are the same as in the S
language, but they are terminated by the <TT>_UNIT</TT> suffix:
<TT>TEXT_UNIT</TT>, <TT>PICTURE_UNIT</TT>, <TT>SYMBOL_UNIT</TT>,
<TT>GRAPHICS_UNIT</TT>. The base type names are written in upper-case
letters.</P>
</DIV>
<DIV class="subsection">
<H3><A name="presattributes">Logical attribute presentation</A></H3>
<P>
After the keyword <TT>ATTRIBUTES</TT>, all attributes which are to have some
effect on the presentation of the element to which they are attached must be
mentioned, along with the corresponding presentation rules. This is true for
both global attributes (which can be attached to all element types) and local
attributes (which can only be attached to certain element types).</P>
<P>
Also mentioned in this section are attributes which imply an effect on
elements in the subtree of the element to which they are attached. The
presentation of these descendants can be modified as a function of the value
of the attribute which they inherit, just as if it was attached to them
directly.</P>
<P>
The specification for each attribute includes the attribute's name, followed
by an optional value specification and, after a colon, a set of rules. The
set of rules must contain at least one rule.</P>
<P>
When there is no value specification, the rules are applied to all elements
which carry the attribute, no matter what their value. When the rules must
only apply when the attribute has certain values, these values must be
specified. Thus, the same attribute can appear in the <TT>ATTRIBUTES</TT>
section several times, with each appearance having a different value
specification. However, reference attributes never have a value specification
and, as a result, can only appear once in the <TT>ATTRIBUTES</TT> section.</P>
<P>
To specify that the presentation rules apply to some of the descendants of the
element having the attribute, the name of the affected element type is given,
between parentheses, after the attribute name. This way, the presentation
rules for the attribute will be applied to the element having the attribute,
if it is of the given type, and to all of its descendants of the given type.
In the case where this type is a <A href="#pairs">mark pair</A>, but only in
this case, the type name can be preceded by the keywords <TT>First</TT> or
<TT>Second</TT>. These keywords indicate whether the rules that follow apply
to the first or second mark of the pair. If the rule must apply to several
different element types, the specification must be repeated for each element
type.</P>
<P>
The specification of values for which the presentation rules will be applied
varies according to the type of the attribute:</P>
<DL>
<DT>numeric attribute</DT>
<DD>If the rules are to apply for one value of the attribute, then the
attribute name is followed by an equals sign and this value. If the rules are
to apply for all values less than (or greater than) a threshold value,
non-inclusive, the attribute name followed by a '<' sign (or a '>' sign,
respectively) and the threshold value. If the rules must apply to a range of
values, the attribute name is followed by the word '<TT>IN</TT>' and the
two bounds of the range, enclosed in brackets and separated by two
periods ('<TT>..</TT>'). In the case of ranges, the values of the bounds
are included in the range.
<P>
The threshold value in the comparisons can be the value of an attribute
attached to an ancestor element. In this case, the attribute name is given
instead of a constant value.</P>
<P>
It is also possible to write rules which apply only when a comparison between
two different attributes of the element's ancestors is true. In this case, the
first attribute name is followed by a comparison keyword and the name of the
second attribute. The comparison keywords are <TT>EQUAL</TT> (simple
equality), <TT>LESS</TT> (non-inclusive less than), and <TT>GREATER</TT>
(non-inclusive greater than).</P>
</DD>
<DT>text attribute</DT>
<DD>If the rules are to apply for one value of the attribute, then the
attribute name is followed by an equals sign and this value.
</DD>
<DT>reference attribute</DT>
<DD>There is never a value specification; the rules apply no matter what
element is designated by the attribute.
</DD>
<DT>enumerated attribute</DT>
<DD>If the rules are to apply for one value of the attribute, then the
attribute name is followed by an equals sign and this value.
</DD>
</DL>
<P>
The order in which the rules associated with a numeric attribute are defined
is important. When multiple sets of rules can be applied, the first set
declared is the one used.</P>
<P>
Rules for attributes have priority over both default rules and rules
associated with element types. The attribute rules apply to the element to
which the attribute is attached. It is the rules which apply to the
surrounding elements (and especially to the descendants) which determine the
effect of the attribute rules on the environment ( and especially on the
terminal elements of the structure).</P>
<PRE>
'ATTRIBUTES' PresAttrSeq
PresAttrSeq = PresAttr < PresAttr > .
PresAttr = AttrID [ '(' [ FirstSec ] ElemID ')' ]
[ AttrRelation ] ':' ViewRuleSeq .
AttrID = NAME .
AttrRelation ='=' AttrVal /
'>' [ '-' ] MinValue /
'<' [ '-' ] MaxValue /
'IN' '[' [ '-' ] LowerBound '..'
[ '-' ] UpperBound ']' /
'GREATER' AttrID /
'EQUAL' AttrID /
'LESS' AttrID .
AttrVal = [ '-' ] EqualNum / EqualText /
AttrValue .
MinValue = NUMBER .
MaxValue = NUMBER .
LowerBound = NUMBER .
UpperBound = NUMBER.
EqualNum = NUMBER .
EqualText = STRING .
AttrValue = NAME .
</PRE>
<P>
In presentation rules associated with a numeric attribute (and only in such
rules), the attribute name can be used in place of a numeric value. In this
case, the value of the attribute is used in the application of the rule. Thus,
the attribute can represent a relation between the size of two boxes, the
height and width of a box, the height of an area where page breaks are
prohibited, the distance between two boxes, the position of the reference axis
of a box, the interline spacing, the indentation of the first line, the
visibility, the depth (z-order), or the character set.</P>
<P>
The presentation rules associated with reference attributes, it is possible to
use the element designated by the attribute as a reference box in a positional
or extent rule. This element is represented in the <A
href="#position">position</A> or <A href="#dimension">extent</A> rule by the
keyword <TT>Referred</TT>.</P>
<BLOCKQUOTE class="example">
<P>
<STRONG>Example:</STRONG></P>
<P>
In all structure schemas, there is a global Language attribute defined as
follows:</P>
<PRE>
ATTR
Language = TEXT;
</PRE>
<P>
The following rules would make French text be displayed in romancharacters and
English text be displayed in italics:</P>
<PRE>
ATTRIBUTES
Language = 'French' :
Style : Roman;
Language = 'English' :
Style : Italics;
</PRE>
<P>
Using these rules, when the user puts the Language attribute with thevalue
'English' on the summary of a document, every character string(terminal
elements) contained in the summary are displayed in italics.See the <A
href="#style"><TT>Style</TT> rule</A>.</P>
</BLOCKQUOTE>
<BLOCKQUOTE class="example">
<P>
<STRONG>Example:</STRONG></P>
<P>
A numeric attribute representing the importance of the part of the document to
which it is attached can be defined:</P>
<PRE>
ATTR
Importance = INTEGER;
</PRE>
<P>
In the presentation schema, the importance of an element is reflectedin the
choice of character size, using the following rules.</P>
<PRE>
ATTRIBUTES
Importance < 2 :
Size : 1;
Importance IN [2..4] :
Size : Importance;
Importance = 10 :
Size : 5;
Importance > 4 :
Size : 4;
</PRE>
<P>
Thus, the character size corresponds to the value of the Importanceattribute;
its value is</P>
<UL>
<LI>the value of the Importance attribute when the value is between 2 and 4
(inclusive),
<LI>1, when the value of the Importance attribute is less than 2,
<LI>4, when the value of the Importance attribute is greater than4,
<LI>5, when the value of the Importance attribute is 10.
</UL>
<P>
The last case (value 5) must be defined before the case which handlesall
Importance values greater than 4, because the two rules are notdisjoint and
the first one defined will have priority. Otherwise,when the Importance
attribute has value 10, the font size will be 4.</P>
</BLOCKQUOTE>
<BLOCKQUOTE class="example">
<P>
<STRONG>Example:</STRONG></P>
<P>
Suppose the structure defines a list element which can have an attribute
defining the type of list (numbered or not):</P>
<PRE>
STRUCT
list (ATTR list_type = enumeration, dash)
= LIST OF (list_item = TEXT);
</PRE>
<P>
Then, the presentation schema could use the attribute placed on thelist
element to put either a dash or a number before the each elementof the
list:</P>
<PRE>
ATTRIBUTES
list_type (list_item) = enumeration :
CreateBefore (NumberBox);
list_type (list_item) = dash :
CreateBefore (DashBox);
</PRE>
</BLOCKQUOTE>
<BLOCKQUOTE class="example">
<P>
<STRONG>Example:</STRONG></P>
<P>
Suppose that two attributes are defined in the structure schema. The first is
a numeric global attribute called ``version''. The other is a local attribute
defined on the root of the document called ``Document_version'':</P>
<PRE>
STRUCTURE Document
ATTR
version = INTEGER;
STRUCT
Document (ATTR Document_version = INTEGER) =
BEGIN
SomeElement ;
...
SomeOtherElement ;
END ;
...
</PRE>
<P>
These attributes can be used in the presentation schema to placechange bars in
the margin next to elements whose version attributehas a value equal to the
Document_version attribute of the root andto place a star in margin of
elements whose version attribute is lessthan the value of the root's
Document_version attribute:</P>
<PRE>
ATTRIBUTES
version EQUAL Document_version :
CreateBefore (ChangeBarBox) ;
version LESS Document_version :
CreateBefore (StarBox) ;
</PRE>
</BLOCKQUOTE>
</DIV>
<DIV class="subsection">
<H3>Value transmission rules</H3>
<P>
The last section of a presentation schema, which is optional, serves to
defines the way in which a document transmits certain values to its
sub-documents. A sub-document is an document <A
href="#inclusion">included</A> without expansion or with partial expansion.
The primary document can transmit to its sub-documents the values of certain
counters or the textual content of certain of its elements, as a function of
their type.</P>
<P>
The sub-documents receive these values in attributes which must be defined in
their structure schema as local attributes of the root element. The types of
these attributes must correspond to the type of the value which they receive:
numeric attributes for receiving the value of a counter, textual attributes
for receiving the content of an element.</P>
<P>
In the structure schema of the primary document, there appears at the end,
after the <TT>TRANSMIT</TT> keyword, a sequence of transmission rules. Each
rule begins with the name of the counter to transmit or of the element type
whose textual content will be transmitted. This name is followed by the
keyword <TT>To</TT> and the name of the attribute of the sub-document to which
the value is transmitted. The sub-document class is indicated between
parentheses after the name of the attribute. The transmission rule ends with
a semicolon.</P>
<PRE>
TransmitSeq = Transmit < Transmit > .
Transmit = TypeOrCounter 'To' ExternAttr
'(' ElemID ')' ';' .
TypeOrCounter = CounterID / ElemID .
ExternAttr = NAME .
</PRE>
<BLOCKQUOTE class="example">
<P>
<STRONG>Example:</STRONG></P>
<P>
Consider a Book document class which includes instances of the Chapter document
class. These classes might have the following schemas:</P>
<PRE>
STRUCTURE Book
STRUCT
Book = BEGIN
Title = Text;
Body = LIST OF (Chapter INCLUDED);
END;
...
STRUCTURE Chapter
STRUCT
Chapter (ATTR FirstPageNum = Integer;
ChapterNum = Integer;
CurrentTitle = Text) =
BEGIN
ChapterTitle = Text;
...
END;
...
</PRE>
<P>
Then the presentation schema for books could define chapter and page counters.
The following transmission rules in the book presentation schema would
transmit values for the three attributes defined at the root of each chapter
sub-document.</P>
<PRE>
PRESENTATION Book;
VIEWS
Full_text;
COUNTERS
ChapterCtr: Rank of Chapter;
PageCtr: Rank of Page(Full_text);
...
TRANSMIT
PageCtr TO FirstPageNum(Chapter);
ChapterCtr TO ChapterNum(Chapter);
Title TO CurrentTitle(Chapter);
END
</PRE>
<P>
Thus, each chapter included in a book can number its pages as a function of
the number of pages preceding it in the book, can make the chapter's number
appear before the number of each of its sections, or can place the title of
the book at the top of each page.</P>
</BLOCKQUOTE>
</DIV>
<DIV class="subsection">
<H3>Presentation rules</H3>
<P>
Whether defining the appearance of a presentation or page layout box, an
element type, or an attribute value, the set of presentation rules that apply
is always defined in the same way.</P>
<P>
Normally, a set of presentation rules is placed between the keywords
<TT>BEGIN</TT> and <TT>END</TT>, the keyword <TT>END</TT> being followed by a
semicolon. The first section of this block defines the rules that apply to
the primary view, if the <A href="#defaultpresrules">default rules</A> are not
completely suitable. Next comes the rules which apply to specific other
views, with a rule sequence for each view for which the default rules are not
satisfactory. If the default rules are suitable for the non-primary views,
there will not be any specific rules for these views. If there is only one
rule which applies to all views then the keywords <TT>BEGIN</TT> and
<TT>END</TT> need not appear.</P>
<P>
For each view, it is only necessary to specify those rules which differ from
the default rules for the view, so that for certain views (or even all views),
there may be no specific rules.</P>
<P>
The specific rules for a non-primary view are introduced by the <A
name="inkeyword"><TT>IN</TT> keyword</A>, followed by the view name. The
rules for that view follow, delimited by the keywords <TT>BEGIN</TT> and
<TT>END</TT>, or without these two keywords when there is only one rule.</P>
<P>
<STRONG>Note:</STRONG> the view name which follows the <TT>IN</TT> keyword
must not be the name of the primary view, since the rules for that view are
found before the rules for the other views.</P>
<P>
Within each block concerning a view, other blocks can appear, delimited by the
same keywords <TT>BEGIN</TT> and <TT>END</TT>. Each of these blocks gathers
the presentation rules that apply, for a given view, only when a given
condition is satisfied. Each block is preceded by a condition introduced by
the <TT>IF</TT> keyword. If such a conditional block contains only one rule,
the keywords <TT>BEGIN</TT> and <TT>END</TT> can be omitted.</P>
<P>
Although the syntax allows any presentation rule to appear in a conditional
block, only <A href="#creation">creation rules</A> are allowed after any
condition; other rules are allowed only after conditions <TT>Within</TT> and
ElemID. In addition, the following rules cannot be conditional:
<TT>PageBreak, LineBreak, Inline, Gather</TT>.</P>
<P>
For a given view, the rules that apply without any condition must appear
before the first conditional block. If some rules apply only when none of the
specified condition holds, they are grouped in a block preceded by the keyword
<TT>Otherwise</TT>, and that block must appear after the last conditionnal
block concerning the same view.</P>
<PRE>
ViewRuleSeq = 'BEGIN' < RulesAndCond > < ViewRules >
'END' ';' /
ViewRules / CondRules / Rule .
RulesAndCond = CondRules / Rule .
ViewRules = 'IN' ViewID CondRuleSeq .
CondRuleSeq = 'BEGIN' < RulesAndCond > 'END' ';' /
CondRules / Rule .
CondRules = CondRule < CondRule >
[ 'Otherwise' RuleSeq ] .
CondRule = 'IF' ConditionSeq RuleSeq .
RulesSeq = 'BEGIN' Rule < Rule > 'END' ';' /
Rule .
</PRE>
<BLOCKQUOTE class="example">
<P>
<STRONG>Example:</STRONG></P>
<P>
The following rules for a report's title make the title visible in the primary
view and invisible in the table of contents and in the formula views (see the
<A href="#visib"><TT>Visibility</TT> rule</A>).</P>
<PRE>
Title : BEGIN
Visibility : 1;
... {Other rules for the primary view}
IN Table_of_contents
Visibility : 0;
IN Formulas
Visibility : 0;
END;
</PRE>
</BLOCKQUOTE>
</DIV>
<DIV class="subsection">
<H3>Conditions applying to presentation rules</H3>
<P>
Many conditions can be applied to presentation rules. Conditions allow
certain presentation rules to apply only in certain cases. These conditions
can be based on the structural position of the element. They can be based on
whether the element has references, and what type of references, whether the
element has attributes, whether the element is empty or not. They can also be
based on the value of a counter.</P>
<P>
It is possible to specify several conditions which must all be true for the
rules to apply.</P>
<P>
A set of conditions is specified by the <TT>IF</TT> keyword. This keyword is
followed by the sequence of conditions, separated by the <TT>AND</TT> keyword.
Each condition is specified by a keyword which defines the condition type. In
some cases, the keyword is followed by other data, which specify the condition
more precisely.</P>
<P>
An elementary condition can be negative; it is then preceded by the
<TT>NOT</TT> keyword.</P>
<P>
When the presentation rule(s) controlled by the condition apply to a reference
element or a reference attribute, an elementary condition can also apply to
element referred by this reference. The <TT>Target</TT> keyword is used for
that purpose. It must appear before the keyword defining the condition
type.</P>
<PRE>
CondRule = 'IF' ConditionSeq RuleSeq .
ConditionSeq = Condition < 'AND' Condition > .
Condition = [ 'NOT' ] [ 'Target' ] ConditionElem .
ConditionElem ='First' / 'Last' /
[ 'Immediately' ] 'Within' [ NumParent ]
ElemID [ ExtStruct ] /
ElemID /
'Referred' / 'FirstRef' / 'LastRef' /
'ExternalRef' / 'InternalRef' / 'CopyRef' /
'AnyAttributes' / 'FirstAttr' / 'LastAttr' /
'UserPage' / 'StartPage' / 'ComputedPage' /
'Empty' /
'(' [ MinMax ] CounterName CounterCond ')' /
CondPage '(' CounterID ')' .
NumParent = [ GreaterLess ] NParent .
GreaterLess = '>' / '<' .
NParent = NUMBER.
ExtStruct = '(' ElemID ')' .
CounterCond ='<' MaxCtrVal / '>' MinCtrVal /
'=' EqCtrVal /
'IN' '[' ['-'] MinCtrBound '.' '.'
['-'] MaxCtrBound ']' .
PageCond ='Even' / 'Odd' / 'One' .
MaxCtrVal = NUMBER .
MinCtrVal = NUMBER .
EqCtrVal = NUMBER .
MaxCtrBound = NUMBER .
MinCtrBound = NUMBER .
</PRE>
<DIV class="subsubsection">
<H4>Conditions based on the logical position of the element</H4>
<P>
The condition can be on the position of the element in the document's logical
structure tree. It is possible to test whether the element is the first
(<TT>First</TT>) or last (<TT>Last</TT>) among its siblings or if it is not
the first (<TT>NOT First</TT>) or not the last (<TT>NOT Last</TT>). These
conditions can be associated only with <A href="#creation">creation
rules</A>.</P>
<P>
It is also possible to test if the element is contained in an element of a
given type (<TT>Within</TT>) or if it is not (<TT>NOT Within</TT>). The type
is indicated after the keyword <TT>Within</TT>. If that element type is
defined in a structure schema which is not the one which corresponds to the
presentation schema, the type name of this element must be followed, between
parentheses, by the name of the structure schema which defines it.</P>
<P>
If the keyword <TT>Within</TT> is preceded by <TT>Immediately</TT>, the
condition is satisfied only if the <EM>parent</EM> element has the type
indicated. If the word <TT>Immediately</TT> is missing, the condition is
satisfied if any <EM>ancestor</EM> has the type indicated.</P>
<P>
An integer <I>n</I> can appear between the keyword <TT>Within</TT> and the
type. It specifies the number of ancestors of the indicated type that must be
present for the condition to be satisfied. If the keyword
<TT>Immediately</TT> is also present, the <I>n</I> immediate ancestors of the
element must have the indicated type. The integer <I>n</I> must be positive
or zero. It can be preceded by <TT><</TT> or <TT>></TT> to indicate a
maximum or minimum number of ancestors. If these symbols are missing, the
condition is satisfied only if it exists exactly <I>n</I> ancestors. When
this number is missing, it is equivalent to > 0.</P>
<P>
If the condition applies to presentation rules associated with an attribute,
in the <TT>ATTRIBUTES</TT> section of the presentation schema, the condition
can be simply an element name. Presentation rules are then executed only if
the attribute is attached to an element of that type. The keyword <TT>NOT</TT>
before the element name indicates that the presentation rules must be executed
only if the element is not of the type indicated.</P>
</DIV>
<DIV class="subsubsection">
<H4>Conditions on references</H4>
<P>
References may be taken into account in conditions, which can be based on the
fact that the element, or one of its ancestors, is designated by a at least
one reference (<TT>Referred</TT>) or by none (<TT>NOT Referred</TT>).</P>
<P>
If the element or attribute to which the condition is attached is a reference,
the condition can be based on the fact that it acts as the first reference to
the designated element (<TT>FirstRef</TT>), or as the last (<TT>LastRef</TT>),
or as a reference to an element located in another document
(<TT>ExternalRef</TT>) or in the same document (<TT>InternalRef</TT>).</P>
<P>
The condition can also be based on the fact that the element is an <A
href="#inclusion">inclusion</A>. This is noted (<TT>CopyRef</TT>).</P>
<P>
Like all conditions, conditions on references can be inverted by the
<TT>NOT</TT> keyword. These conditions can be associated only with <A
href="#creation">creation rules</A>.</P>
</DIV>
<DIV class="subsubsection">
<H4>Conditions on logical attributes</H4>
<P>
The condition can be based on the presence or absence of attributes associated
with the element, no matter what the attributes or their values. The
<TT>AnyAttributes</TT> keyword expresses this condition.</P>
<P>
If the condition appears in the presentation rules of an attribute, the
<TT>FirstAttr</TT> and <TT>LastAttr</TT> keywords can be used to indicate that
the rules must only be applied if this attribute is the first attribute for
the element or if it is the last (respectively). These conditions can also be
inverted by the <TT>NOT</TT> keyword. These conditions can be associated only
with <A href="#creation">creation rules</A>.</P>
<P>
It is also possible to apply certain presentation rules only when the element
being processed or one of its ancestors has a certain attribute, perhaps with
a certain value. This can be done in the <A
href="#presattributes"><TT>ATTRIBUTES</TT> section</A>.</P>
</DIV>
<DIV class="subsubsection">
<H4>Conditions on page breaks</H4>
<P>
The page break base type (and only this type) can use the following
conditions: <TT>ComputedPage</TT>, <TT>StartPage</TT>, and <TT>UserPage</TT>.
The <TT>ComputedPage</TT> condition indicates that the presentation rule(s)
should apply if the page break was created automatically by Thot; the
<TT>StartPage</TT> condition is true if the page break is generated before the
element by the <TT>Page</TT> rule; and the <TT>UserPage</TT> condition applies
if the page break was inserted by the user.</P>
<P>
These conditions can be associated only with <A href="#creation">creation
rules</A>.</P>
</DIV>
<DIV class="subsubsection">
<H4>Conditions on the element's content</H4>
<P>
The condition can be based on whether or not the element is empty. An element
which has no children or whose leaves are all empty is considered to be empty
itself. This condition is expressed by the <TT>Empty</TT> keyword, optionally
preceded by the <TT>NOT</TT> keyword. This condition can be associated only
with <A href="#creation">creation rules</A>.</P>
</DIV>
<DIV class="subsubsection">
<H4>Conditions on counters</H4>
<P>
Presentation rules can apply when the counter's value is one, is even or odd,
is equal, greater than or less than a given value or falls in a range of
values. This is particularly useful for creating header and footer boxes.
These conditions can be associated only with <A href="#creation">creation
rules</A>.</P>
<P>
To compare the value of a counter to a given value, a comparison is given
between parentheses. The comparison is composed of the counter name followed
by an equals, greater than, or less than sign and the value to which the
counter will be compared. A test for whether or not a counter's value falls
in a range also appears within parentheses. In this case, the counter name is
followed by the <TT>IN</TT> keyword and the range definition within brackets.
The <TT>Even</TT>, <TT>Odd</TT> and <TT>One</TT> are used to test a counter's
value and are followed by the counter name between parentheses.</P>
<P>
The list of possible conditions on counters is:</P>
<DL>
<DT><TT>Even (Counter)</TT></DT>
<DD>the box is created only if the counter has an even value.
</DD>
<DT><TT>Odd (Counter)</TT></DT>
<DD>the box is created only if the counter has an odd value.
</DD>
<DT><TT>One (Counter)</TT></DT>
<DD>the box is created only the counter's value is 1.
</DD>
<DT><TT>NOT One (Counter)</TT></DT>
<DD>the box is created, unless thecounter's value is 1.
</DD>
<DT><TT>(Counter < Value)</TT></DT>
<DD>the box is created only if thecounter's value is less than Value.
</DD>
<DT><TT>(Counter > Value)</TT></DT>
<DD>the box is created only if thecounter's value is greater than Value.
</DD>
<DT><TT>(Counter = Value)</TT></DT>
<DD>the box is created only if thecounter's value is equal to Value.
</DD>
<DT><TT>NOT (Counter = Value)</TT></DT>
<DD>the is created only if thecounter's value is different than Value.
</DD>
<DT><TT>(Counter IN [MinValue..MaxValue])</TT></DT>
<DD>the box is createdonly if the counter's value falls in the range bounded
by MinValue andMaxValue (inclusive).
</DD>
<DT><TT>NOT (Counter IN [MinValue..MaxValue])</TT></DT>
<DD>the box iscreated only if the value of the counter does not fall in the
range boundedby MinValue and MaxValue (inclusive).
</DD>
</DL>
<P>
<STRONG>Note:</STRONG> the <TT>NOT Even</TT> and <TT>NOT Odd</TT> conditions
are syntactically correct but can be expressed more simply by <TT>Odd</TT> and
<TT>Even</TT>, respectively.</P>
</DIV>
</DIV>
<DIV class="subsection">
<H3><A name="presrule">A presentation rule</A></H3>
<P>
A presentation rule defines either a presentation parameter or presentation
function. The parameters are:</P>
<UL>
<LI>the position of the vertical and horizontal reference axes of the box,
<LI>the position of the box in relation to other boxes,
<LI>the height or width of the box, with overflow exceptions,
<LI>the characteristics of the lines contained in the box: linespacing,
indentation of the first line, justification, hyphenation,
<LI>the conditions for breaking the box across pages,
<LI>the characteristics of the characters contained in the box: size, font,
style, underlining,
<LI>the depth of the box among overlapping boxes (often called stacking
order),
<LI>the characteristics of graphic elements contained in the box: style and
thickness of lines, fill pattern for closed objects,
<LI>the colors in text, graphics, pictures, and symbols contained in the box
are displayed or printed,
<LI>for presentation boxes only, the contents of the box.
</UL>
<P>
The <A name="presfunct">presentation functions</A>are:</P>
<UL>
<LI>the creation of a presentation box
<LI>the line-breaking or page-breaking style,
<LI>the copying of another box.
</UL>
<P>
For each box and each view, every presentation parameter is defined once and
only once, either explicitly or by the <A href="#defaultpresrules">default
rules</A>. In contrast, presentation functions are not obligatory and can
appear many times for the same element. for example an element can create
many presentation boxes. Another element may not use any presentation
functions.</P>
<P>
Each rule defining a presentation parameter begins with a keyword followed by
a colon. the keyword indicates the parameter which is the subject of the rule.
After the keyword and the colon, the remainder of the rule varies. All rules
are terminated by a semicolon.</P>
<PRE>
Rule = PresParam ';' / PresFunc ';' .
PresParam ='VertRef' ':' PositionHoriz /
'HorizRef' ':' PositionVert /
'VertPos' ':' VPos /
'HorizPos' ':' HPos /
'Height' ':' Dimension /
'Width' ':' Dimension /
'VertOverflow' ':' Boolean /
'HorizOverflow' ':' Boolean /
'LineSpacing' ':' DistanceInherit /
'Indent' ':' DistanceInherit /
'Adjust' ':' AdjustInherit /
'Justify' ':' BoolInherit /
'Hyphenate' ':' BoolInherit /
'PageBreak' ':' Boolean /
'LineBreak' ':' Boolean /
'InLine' ':' Boolean /
'NoBreak1' ':' AbsDist /
'NoBreak2' ':' AbsDist /
'Gather' ':' Boolean /
'Visibility' ':' NumberInherit /
'Size' ':' SizeInherit /
'Font' ':' NameInherit /
'Style' ':' StyleInherit /
'Underline' ':' UnderLineInherit /
'Thickness' ':' ThicknessInherit /
'Depth' ':' NumberInherit /
'LineStyle' ':' LineStyleInherit /
'LineWeight' ':' DistanceInherit /
'FillPattern' ':' NameInherit /
'Background' ':' NameInherit /
'Foreground' ':' NameInherit .
'Content' ':' VarConst .
PresFunc = Creation '(' BoxID ')' /
'Line' /
'NoLine' /
'Page' '(' BoxID ')' /
'Copy' '(' BoxTypeToCopy ')' .
</PRE>
</DIV>
<DIV class="subsection">
<H3>Box axes</H3>
<P>
The position of the middle axes <TT>VMiddle</TT> and <TT>HMiddle</TT> in
relation to their box is always calculated automatically as a function of the
height and width of the box and is not specified by the presentation rules. In
the presentation schema, these middle axes are used only to position their box
with respect to another by specifying the distance between the middle axis and
an axis or a side of another box (see the <A href="#position">relative
position</A>).</P>
<P>
The reference axes of a box are also used to position their box in relation to
another, but in contrast to the middle axes, the presentation schema must make
their position explicit, either in relation to a side or the middle axis of
the box itself, or in relation to an axis of an enclosed box.</P>
<P>
Only boxes of base elements have predefined reference axes. For character
string boxes, the horizontal reference axis is the baseline of the characters
(the line which passes immediately under the upper-case letters, ignoring the
letter Q) and the vertical reference axis is at the left edge of the first
character of the string.</P>
<P>
The positions of a box's reference axes are defined by the <TT>VertRef</TT>
and <TT>HorizRef</TT> rules which specify the <A href="#distance">distance</A>
between the reference axis and an axis or parallel side of the same box or of
an enclosed box.</P>
<PRE>
'VertRef' ':' PositionHoriz
'HorizRef' ':' PositionVert
</PRE>
<BLOCKQUOTE class="example">
<P>
<STRONG>Example:</STRONG></P>
<P>
If, in the structure schema for mathematical formulas, the fraction element is
defined by</P>
<PRE>
Fraction = BEGIN
Numerator = Expression;
Denominator = Expression;
END;
</PRE>
<P>
then the horizontal reference axis of the fraction can be positioned on top of
the denominator by the rule:</P>
<PRE>
Fraction :
BEGIN
HorizRef : Enclosed Denominator . Top;
...
END;
</PRE>
<P>
To put the horizontal reference axis of a column at its middle:</P>
<PRE>
Column :
BEGIN
HorizRef : * . HMiddle;
...
END;
</PRE>
</BLOCKQUOTE>
</DIV>
<DIV class="subsection">
<H3><A name="distunits">Distance units</A></H3>
<P>
Some distances and dimensions appear in many rules of a presentation schema,
especially in position rules (<TT>VertPos, HorizPos</TT>), in extent rules for
boxes (<TT>Height, Width</TT>), in rules defining lines (<TT>LineSpacing,
Indent</TT>), in rules controlling pagination (<TT>NoBreak1, NoBreak2</TT>)
and in rules specifying the thickness of strokes (<TT>LineWeight</TT>).</P>
<P>
In all these rules, the distance or extent can be expressed</P>
<UL>
<LI>either in relative units, which depend on the size of the characters in
the current font: height of the element's font or height of the letter 'x',
<LI>or in absolute units: centimeter, millimeter, inch, typographer's point,
pica or pixel.
</UL>
<P>
Units can be chosen freely. Thus, it is possible to use relative units inone
rule, centimeters in the next rule, and typographer's points inanother.</P>
<P>
Absolute units are used to set rigid rules for the appearance of documents. In
contrast, relative units allow changes of scale. The editor lets the value of
relative units be changed dynamically. Such changes affect every box using
relative units simultaneously and in the same proportion. Changing the value
of the relative units affects the size of the characters and graphical
elements, and the size of the boxes and the distances between them.</P>
<P>
A <A name="distance">distance</A> or extent is specified by a number, which
may be followed by one or more spaces and a units keyword. When there is no
units keyword, the number specifies the number of relative units, where a
relative unit is the height of a character in the current font (an em). When
the number is followed by a units keyword, the keyword indicates the type of
absolute units:</P>
<UL>
<LI><TT>em</TT>: height of the element's font,
<LI><TT>ex</TT>: height of the letter 'x',
<LI><TT>cm</TT>: centimeter,
<LI><TT>mm</TT>: millimeter,
<LI><TT>in</TT>: inch (1 in = 2.54 cm),
<LI><TT>pt</TT>: point (1 pt = 1/72 in),
<LI><TT>pc</TT>: pica (1 pc = 12 pt),
<LI><TT>px</TT>: pixel.
</UL>
<P>
Whatever the chosen unit, relative or absolute, the number is not necessarily
an integer and may be expressed in fixed point notation (using the American
convention of a period to express the decimal point).</P>
<P>
If the distance appears in a presentation rule for a numeric attribute, the
number can be replaced by the name of an attribute. In this case, the value
of the attribute is used. Obviously, the attribute name cannot be followed by
a decimal point and a fractional part, but it can be followed a units keyword.
However, the choice of units is limited to em, ex, pt and px.</P>
<PRE>
Distance = [ Sign ] AbsDist .
Sign ='+' / '-' .
AbsDist = IntegerOrAttr [ '.' DecimalPart ]
[ Unit ].
IntegerOrAttr = IntegerPart / AttrID .
IntegerPart = NUMBER .
DecimalPart = NUMBER .
Unit ='em' / 'ex' / 'cm' / 'mm' / 'in' / 'pt' /
'pc' / 'px' / '%' .
</PRE>
<BLOCKQUOTE class="example">
<P>
<STRONG>Example:</STRONG></P>
<P>
The following rules specify that a box has a height of 10.5 centimeters and a
width of 5.3 ems:</P>
<PRE>
Height : 10.5 cm;
Width : 5.3;
</PRE>
</BLOCKQUOTE>
</DIV>
<DIV class="subsection">
<H3><A name="position">Relative positions</A></H3>
<P>
The positioning of boxes uses the eight axes and sides, the sides generally
being used to define the juxtapositioning (vertical or horizontal) of boxes,
the middle axes being used to define centering, and the reference axes being
used for alignment.</P>
<P>
Two rules allow a box to placed relative to other boxes. The <TT>VertPos</TT>
rule positions the box vertically. The <TT>HorizPos</TT> rule positions the
box horizontally. It is possible that a box's position could be entirely
determined by other boxes positioned relative to it. In this case, the
position is implicit and the word <TT>nil</TT> can be used to specify that no
position rule is needed. Otherwise, an explicit rule must be given by
indicating the axis or side which defines the position of the box, followed by
an equals sign and the distance between between this axis or side and a
parallel axis or side of another box, called the reference box. The box for
which the rule is written will be positioned relative to the reference
box.</P>
<PRE>
'VertPos' ':' VPos
'HorizPos' ':' HPos
HPos = 'nil' / VertAxis '=' HorizPosition
[ 'UserSpecified' ].
VPos = 'nil' / HorizAxis '=' VertPosition
[ 'UserSpecified' ].
VertAxis = 'Left' / 'VMiddle' / 'VRef' / 'Right' .
HorizAxis = 'Top' / 'HMiddle' / 'HRef' / 'Bottom' .
</PRE>
<P>
The reference box is an adjacent box: enclosing, enclosed or adjacent. When a
rule is associated with a reference type attribute (and only in this case), it
can be a box of the element designated by the attribute. The reference box
can be either a presentation box previously defined in the <TT>BOXES</TT>
section of the schema and created by a creation function, or the box
associated with a structured element.</P>
<P>
The structural position of the reference box (relative to the box for which
the rule is being written) is indicated by a keyword: <TT>Enclosing</TT>,
<TT>Enclosed</TT>, or, for sibling boxes, <TT>Previous</TT> or <TT>Next</TT>.
The reference attributes, or presentation boxes created by a reference
attribute, the <TT>Referred</TT> keyword may be used to designate the element
which the reference points to. The keyword <TT>Creator</TT> can be used in
rules for presentation boxes to designate the box of the element which created
the presentation box. Finally, the <TT>Root</TT> keyword can be used to
designate the root of the document.</P>
<P>
When the keyword is ambiguous, it is followed by a name of a type or
presentation box which resolves the ambiguity (the <TT>Creator</TT> and
<TT>Root</TT> keywords are never ambiguous). If this name is not given, then
the first box encountered is used as the reference box. It is also possible to
use just the name of a type or presentation box without an initial keyword. In
this case, a sibling having that name will be used. If the name is preceded
by the keyword <TT>NOT</TT>, then the reference box will be the first box
whose type is not the named one. In place of the box or type name, the
keywords <TT>AnyElem</TT> and <TT>AnyBox</TT> can be used, representing
respectively, any structured element box and any presentation box. A type
name may be preceded by a star in order to resolve the ambiguity in the
special case where the structure schema defines an <A
href="#references">inclusion</A> without expansion (or with partial expansion)
of the same type as an element of the scheme. For mark pairs (and only for <A
href="#pairs">mark pairs</A>) the type name <EM>must</EM> be preceded by the
<TT>First</TT> or <TT>Second</TT> keyword, which indicates which of the two
marks of the pair should be used as the reference box.</P>
<P>
The star character ('<TT>*</TT>') used alone designates the box to which the
rule applies (in this case, it is obviously useless to specify the type of the
reference box).</P>
<P>
The keywords <TT>Enclosing</TT> and <TT>Enclosed</TT> can be used no matter
what constructor defines the type to which the rule applies. When applied to
the element which represents the entire document, <TT>Enclosing</TT>
designates the window or page in which the document's image is displayed for
the view to which the rule applies. A box or type name without a keyword is
used for aggregate elements and designates another element of the same
aggregate. It can also be used to designate a presentation or page layout
box. The keywords <TT>Previous</TT> and <TT>Next</TT> are primarily used to
denote list elements, but can also be used to denote elements of an
aggregate.</P>
<P>
In the position rule, the structural position relative to the reference box is
followed, after a period, by the name of an axis or side. The rule specifies
its node's position as being some distance from this axis or side of the
reference box. If this distance is zero, then the distance does not appear in
the rule. Otherwise, it does appear as a positive or negative number (the
sign is required for negative numbers). The sign takes into account the
orientation of the coordinate axes: for top to bottom for the vertical axis
and from left to right for the horizontal axis. Thus, a negative distance in
a vertical position indicates that the side or axis specified in the rule is
above the side or axis of the reference box.</P>
<P>
The distance can be followed by the <TT>UserSpecified</TT> keyword (even if
the distance is nil and does not appear, the <TT>UserSpecified</TT> keyword
can be used). It indicates that when the element to which the rule applies is
being created, the editor will ask the user to specify the distance himself,
using the mouse. In this case, the distance specified in the rule is a
default distance which is suggested to the user but can be modified. The
<TT>UserSpecified</TT> keyword can be used either in the vertical position
rule, the horizontal position rule, or both.</P>
<PRE>
VertPosition = Reference '.' HorizAxis [ Distance ] .
HorizPosition = Reference '.' VertAxis [ Distance ] .
Reference ='Enclosing' [ BoxTypeNot ] /
'Enclosed' [ BoxTypeNot ] /
'Previous' [ BoxTypeNot ] /
'Next' [ BoxTypeNot ] /
'Referred' [ BoxTypeNot ] /
'Creator' /
'Root' /
'*' /
BoxOrType .
BoxOrType = BoxID /
[ '*' ] [ FirstSec ] ElemID /
'AnyElem' / 'AnyBox' .
BoxTypeNot = [ 'NOT' ] BoxOrType .
</PRE>
<BLOCKQUOTE class="example">
<P>
<STRONG>Example:</STRONG></P>
<P>
If a <A name="expos1">report</A>is defined by by the following
structure schema:</P>
<PRE>
Report = BEGIN
Title = Text;
Summary = Text;
Keywords = Text;
...
END;
</PRE>
<P>
then the presentation schema could contain the rules:</P>
<PRE>
Report : BEGIN
VertPos : Top = Enclosing . Top;
HorizPos : Left = Enclosing . Left;
...
END;
</PRE>
<P>
These rules place the <A name="reportexample">report</A> in the upper left
corner of the enclosing box, which is the window in which the document is being
edited.</P>
<PRE>
Title : BEGIN
VertPos : Top = Enclosing . Top + 1;
HorizPos : VMiddle = Enclosing . VMiddle;
...
END;
</PRE>
<P>
The top of the title is one line (a line has the height of the characters of
the title) from the top of the report, which is also the top of the editing
window. The title is centered horizontally in the window (see <A
href="#posdim">figure</A>).</P>
<PRE>
Summary : BEGIN
VertPos : Top = Title . Bottom + 1.5;
HorizPos : Left = Enclosing . Left + 2 cm;
...
END;
</PRE>
<P>
The top of the summary is place a line and a half below the bottom of the title
and is shifted two centimeters from the side of the window.</P>
</BLOCKQUOTE>
<BLOCKQUOTE class="example">
<P>
<STRONG>Example:</STRONG></P>
<P>
Suppose there is a <A name="expos2">Design</A> logical structure which contains
graphical elements:</P>
<PRE>
Design = LIST OF (ElemGraph = GRAPHICS);
</PRE>
<P>
The following rules allow the user to freely choose the position of each
element when it is created:</P>
<PRE>
ElemGraph =
BEGIN
VertPos : Top = Enclosing . Top + 1 cm UserSpecified;
HorizPos: Left = Enclosing . Left UserSpecified;
...
END;
</PRE>
<P>
Thus, when a graphical element is created, its default placement is at the left
of the window and 1 cm from the top, but the user can move it immediately,
simply by moving the mouse.</P>
</BLOCKQUOTE>
</DIV>
<DIV class="subsection">
<H3><A name="dimension">Box extents</A></H3>
<P>
The extents (height and width) of each box are defined by the two rules
<TT>Height</TT> and <TT>Width</TT>. There are three types of extents: fixed,
relative, and elastic.</P>
<DIV class="subsubsection">
<H4>Fixed extents</H4>
<P>
A fixed dimension sets the height or width of the box independently of all
other boxes. It is expressed in <A href="#distunits">distance units</A>. The
extent can be followed by the <TT>UserSpecified</TT> keyword which indicates
that when the element to which the rule applies is being created, the editor
will ask the user to specify the extent himself, using the mouse. In this
case, the extent specified in the rule is a default extent which is suggested
to the user but can be modified. The <TT>UserSpecified</TT> keyword can be
used either in the <TT>Height</TT> rule, the <TT>Width</TT> rule, or both.</P>
<P>
A fixed extent rule can be ended by the <TT>Min</TT> keyword, which signifies
that the indicated value is a minimum, and that, if the contents of the box
require it, a larger extent is possible.</P>
<PRE>
'Height' ':' Dimension
'Width' ':' Dimension
Dimension = AbsDist [ 'UserSpecified' ] [ 'Min' ] /
...
</PRE>
<BLOCKQUOTE class="example">
<P>
<STRONG>Example:</STRONG></P>
<P>
Continuing with the <A href="#expos2">previous example</A>, it is possible to
allow the user to choose the size of each graphical element as it is
created:</P>
<PRE>
ElemGraph : BEGIN
Width : 2 cm UserSpecified;
Height : 1 cm UserSpecified;
...
END;
</PRE>
<P>
Thus, when a graphical element is create, it is drawn by default with a width
of 2 cm and a height of 1 cm, but the user is free to resize it immediately
with the mouse.</P>
<PRE>
Summary : BEGIN
Height : 5 cm Min;
...
END;
Keywords : BEGIN
VertPos : Top = Summary . Bottom;
...
END;
</PRE>
</BLOCKQUOTE>
</DIV>
<DIV class="subsubsection">
<H4>Relative extents</H4>
<P>
A relative extent determines the extent as a function of the extent of another
box, just as a relative position places a box in relation to another. The
reference box in an extent rule is designated using the same syntax as is used
in a relative position rule. It is followed by a period and a <TT>Height</TT>
or <TT>Width</TT> keyword, depending on the extent being referred to. Next
comes the relation between the extent being defined and the extent of the
reference box. This relation can be either a percentage or a difference.</P>
<P>
A percentage is indicated by a star (the multiplication symbol) followed by
the numeric percentage value (which may be greater than or less than 100) and
the percent (`%') character. A difference is simply indicated by a signed
difference.</P>
<P>
If the rule appears in the presentation rules of a numeric attribute, the
percentage value can be replaced by the name of the attribute. This attribute
is then used as a percentage. The attribute can also be used as part of a <A
href="#distance">difference</A>.</P>
<P>
Just as with a fixed extent, a relative extent rule can end with the
<TT>Min</TT> keyword, which signifies that the extent is a minimum and that,
if the contents of the box require it, a larger extent is possible.</P>
<P>
A special case of relative extent rules is:</P>
<PRE>
Height : Enclosed . Height;
</PRE>
<P>
or</P>
<PRE>
Width : Enclosed . Width;
</PRE>
<P>
which specifies that the box has a height (or width) such that itencloses all
the boxes which it contains, excluding boxes having a rule<TT>VertOverflow:
Yes;</TT>ou <TT>HorizOverflow:Yes;</TT>.</P>
<P>
<STRONG>Note:</STRONG> character strings (type <TT>TEXT_UNIT</TT>) generally
must use the sum of the widths of the characters which compose them as their
width, which is expressed by the rule:</P>
<PRE>
TEXT_UNIT :
Width : Enclosed . Width;
</PRE>
<P>
If this rule is not the default <TT>Width</TT>rule, it must be givenexplicitly
in the <TT>RULES</TT>section which defines the presentationrules of the
logical elements.</P>
<PRE>
'Height' ':' Extent
'Width' ':' Extent
Extent = Reference '.' HeightWidth [ Relation ]
[ 'Min' ] / ...
HeightWidth ='Height' / 'Width' .
Relation ='*' ExtentAttr '%' / Distance .
ExtentAttr = ExtentVal / AttrID .
ExtentVal = NUMBER .
</PRE>
<BLOCKQUOTE class="example">
<P>
<STRONG>Example:</STRONG></P>
<P>
Completing the <A href="#expos1">above example</A>, it is possible to specify
that the report takes its width from the editing window and its height from the
size of its contents (this can obviously be greater than that of the
window):</P>
<PRE>
Report : BEGIN
Width : Enclosing . Width;
Height : Enclosed . Height;
...
END;
</PRE>
<P>
Then, the following rules make the title occupy 60% of the width of the report
(which is that of the window) and is broken into centered lines of this width
(see the <A href="#linerule"><TT>Line</TT> rule</A>).</P>
<PRE>
Title : BEGIN
Width : Enclosing . Width * 60%;
Height : Enclosed . Height;
Line;
Adjust : VMiddle;
...
END;
</PRE>
<P>
The summary occupy the entire width of the window, with the exceptionof a 2 cm
margin reserved by the horizontal position rule:</P>
<PRE>
Summary : BEGIN
Width : Enclosing . Width - 2 cm;
Height : Enclosed . Height;
...
END;
</PRE>
<P>
This set of rules, plus the <A href="#reportexample">position rules given
above</A>, produce the layout of boxes shown in the following<A
href="#posdim">figure</A>.</P>
<DIV class="figure">
<HR>
<PRE>
-------------------------------------------------------------
| Window and Report ^ |
| | 1 line |
| v |
| ------------------------------------- |
| | | |
: 20% : Title : 20% :
:<--------->: :<--------->:
: : 60% : :
: :<--------------------------------->: :
| | | |
| ------------------------------------- |
| ^ |
| | 1.5 line |
| | |
| v |
| ---------------------------------------------------|
| 2 cm | |
|<------>| Summary |
: : :
</PRE>
<P align=center>
<EM><A name="posdim">Box position and extent</A><EM></EM></EM></P>
<HR>
</DIV>
</BLOCKQUOTE>
</DIV>
<DIV class="subsubsection">
<H4>Elastic extents</H4>
<P>
The last type of extent is the elastic extent. Either one or both extents can
be elastic. A box has an elastic extent when two opposite sides are linked by
distance constraints to two sides or axes of other boxes.</P>
<P>
One of the sides of the elastic box is linked by a position rule
(<TT>VertPos</TT> or <TT>HorizPos</TT>) to a neighboring box. The other side
is link to another box by a <TT>Height</TT> or <TT>Width</TT> rule, which
takes the same form as the position rule. For the elastic box itself, the
notions of sides (left or right, top or bottom) are fuzzy, since the movement
of either one of the two reference boxes can, for example, make the left side
of the elastic box move to the right of its right side. This is not
important. The only requirement is that the two sides of the elastic box used
in the position and extent rule are opposite sides of the box.</P>
<PRE>
'Height' ':' Extent
'Width' ':' Extent
Extent = HPos / VPos / ...
</PRE>
<BLOCKQUOTE class="example">
<P>
<STRONG>Example:</STRONG></P>
<P>
Suppose we want to draw an elastic arrow or line between the middle of the
bottom side of box A and the upper left corner of box B. To do this, we would
define a graphics box whose upper left corner coincides with the middle of the
bottom side of A (a position rule) and whose lower right corner coincides with
with the upper left corner of B (dimension rules):</P>
<PRE>
LinkedBox :
BEGIN
VertPos : Top = A .Bottom;
HorizPos : Left = A . VMiddle;
Height : Bottom = B . Top;
Width : Right = B . Left;
END;
</PRE>
</BLOCKQUOTE>
<BLOCKQUOTE class="example">
<P>
<STRONG>Example:</STRONG></P>
<P>
The element SectionTitle creates a presentation box called SectionNum which
contains the number of the section. Suppose we want to align the SectionNum
and SectionTitle horizontally, have the SectionNum take its width from its
contents (the section number), have the SectionTitle box begin 0.5 cm to the
right of the SectionNum box and end at the right edge of its enclosing box.
This would make the SectionTitle box elastic, since its width is defined by the
position of its left and right sides. The following rules produce this
effect:</P>
<PRE>
SectionNum :
BEGIN
HorizPos : Left = Enclosing . Left;
Width : Enclosed . Width;
...
END;
SectionTitle :
BEGIN
HorizPos : Left = SectionNum . Right + 0.5 cm;
Width : Right = Enclosing . Right;
...
END;
</PRE>
</BLOCKQUOTE>
</DIV>
</DIV>
<DIV class="subsection">
<H3>Overflow</H3>
<P>
A boxes corresponding to a structural element normally contain all boxes
corresponding to the elements of its subtree. However, in some cases, it
could be necessary to allow a box to jut out from its parent box. Two
presentation rules indicate that such an overflow is allowed, one for
horizontal overflow, one for vertical overflow.</P>
<P>
Each of these rules is expressed by a keyword followed by a colon and the
keyword <TT>Yes</TT> or <TT>No</TT>.</P>
<PRE>
'VertOverflow' ':' Boolean /
'HorizOverflow' ':' Boolean .
Boolean = 'Yes' / 'No' .
</PRE>
</DIV>
<DIV class="subsection">
<H3>Inheritance</H3>
<P>
A presentation parameter can be defined by reference to the same parameter of
another box in the tree of boxes. These structural links are expressed by
kinship. The reference box can be that of the element immediately above in
the structure (<TT>Enclosing</TT>), two levels above (<TT>GrandFather</TT>),
immediately below (<TT>Enclosed</TT>) or immediately before
(<TT>Previous</TT>). In the case of a presentation box, and only in that
case, the reference box may be the element which created the presentation box
(<TT>Creator</TT>).</P>
<P>
Kinship is expressed in terms of the logical structure of the document and not
in terms of the tree of boxes. The presentation box cannot transmit any of
their parameters by inheritance; only structured element boxes can do so. As
an example, consider an element B which follows an element A in the logical
structure. The element B creates a presentation box P in front of itself,
using the <TT>CreateBefore</TT> rule (see the <A href="#creation">creation
rules</A>). If element B's box inherits its character style using the
<TT>Previous</TT> kinship operation, it gets its character style from A's box,
not from P's box. Inheritance works differently for positions and extents,
which can refer to presentation boxes.</P>
<P>
The inherited parameter value can be the same as that of the reference box.
This is indicated by an equals sign. However, for numeric parameters, a
different value can be obtained by adding or subtracting a number from the
reference box's parameter value. Addition is indicated by a plus sign before
the number, while subtraction is specified with a minus sign. The value of a
parameter can also be given a maximum (if the sign is a plus) or minimum (if
the sign is a minus).</P>
<P>
If the rule is being applied to a numeric attribute, the number to add or
subtract can be replaced by the attribute name. The value of a maximum or
minimum may also be replaced by an attribute name. In these cases, the value
of the attribute is used.</P>
<PRE>
Inheritance = Kinship InheritedValue .
Kinship ='Enclosing' / 'GrandFather' / 'Enclosed' /
'Previous' / 'Creator' .
InheritedValue ='+' PosIntAttr [ 'Max' maximumA ] /
'-' NegIntAttr [ 'Min' minimumA ] /
'=' .
PosIntAttr = PosInt / AttrID .
PosInt = NUMBER .
NegIntAttr = NegInt / AttrID .
NegInt = NUMBER .
maximumA = maximum / AttrID .
maximum = NUMBER .
minimumA = minimum / AttrID .
minimum = NUMBER .
</PRE>
<P>
The parameters which can be obtained by inheritance are justification,
hyphenation, interline spacing, character font (font family), font style, font
size, visibility, indentation, underlining, alignment of text, stacking order
of objects, the style and thickness of lines, fill pattern and the colors of
lines and characters.</P>
</DIV>
<DIV class="subsection">
<H3><A name="linerule">Line breaking</A></H3>
<P>
The <TT>Line</TT> rule specifies that the contents of the box should be broken
into lines: the boxes included in the box to which this rule is attached are
displayed one after the other, from left to right, with their horizontal
reference axes aligned so that they form a series of lines. The length of
these lines is equal to the width of the box to which the <TT>Line</TT> rule
is attached.</P>
<P>
When an included box overflows the current line, it is either carried forward
to the next line, cur, or left the way it is. The <A
href="#breakcond"><TT>LineBreak</TT> rule</A> is used to allow or prevent the
breaking of included boxes. If the included box is not breakable but is
longer than the space remaining on the line, it is left as is. When a
character string box is breakable, the line is broken between words or, if
necessary, by <A href="#hyphenaterule">hyphenating a word</A>. When a
compound box is breakable, the box is transparent in regard to line breaking.
The boxes included in the compound box are treated just like included boxes
which have the <TT>LineBreak</TT> rule. Thus, it is possible to traverse a
complete subtree of boxes to line break the text leaves of a complex
structure.</P>
<P>
The relative position rules of the included boxes are ignored, since the boxes
will be placed according to the line breaking rules.</P>
<P>
The <TT>Line</TT> rule does not have a parameter. The characteristics of the
lines that will be constructed are determined by the <TT>LineSpacing</TT>,
<TT>Indent</TT>, <TT>Adjust</TT>, <TT>Justify</TT>, and <TT>Hyphenate</TT>
rules. Moreover, the <A href="#inlinerule"><TT>Inline</TT> rule</A> permits
the exclusion of certain elements from the line breaking process.</P>
<P>
When the <TT>Line</TT> rule appears in the rules sequence of a non-primary
view, it applies only to that view, but when the <TT>Line</TT> rule appears in
the rules sequence of the primary view, it also applies to the other views by
default, except for those views which explicitly invoke the <TT>NoLine</TT>
rule. Thus, the <TT>NoLine</TT> rule can be used in a non-primary view to
override the primary view's <TT>Line</TT> rule. The <TT>NoLine</TT> rule must
not be used with the primary view because the absence of the <TT>Line</TT>
rule has the same effect. Like the <TT>Line</TT> rule, the <TT>NoLine</TT>
rule does not take any parameters.</P>
<PRE>
'Line'
'NoLine'
</PRE>
<DIV class="subsubsection">
<H4><A name="linespacing">Line spacing</A></H4>
<P>
The <TT>LineSpacing</TT> rule defines the line spacing to be used in the line
breaking process. The line spacing is the distance between the baselines
(horizontal reference axis) of the successive lines produced by the
<TT>Line</TT> rule. The value of the line spacing can be specified as a
constant or by inheritance. It is expressed in any of the available <A
href="#distunits">distance units</A>.</P>
<P>
Inheritance allows the value to be obtained from a relative in the structure
tree, either without change (an equals sign appears after the inheritance
keyword), with a positive difference (a plus sign), or a negative difference
(a minus sign). When the rule uses a difference, the value of the difference
follows the sign and is expressed as a <A href="#distunits">distance</A>.</P>
<PRE>
'LineSpacing' ':' DistOrInherit
DistOrInherit = Kinship InheritedDist / Distance .
InheritedDist = '=' / '+' AbsDist / '-' AbsDist .
</PRE>
<P>
When the line spacing value (or its difference from another element) is
expressed in relative units, it changes with the size of the characters. Thus,
when a larger font is chosen for a part of the document, the line spacing of
that part expands proportionally. In contrast, when the line spacing value is
expressed in absolute units (centimeters, inches, typographer's points), it is
independent of the characters, which permits the maintenance of a consistent
line spacing, whatever the character font. Either approach can be taken,
depending on the desired effect.</P>
</DIV>
<DIV class="subsubsection">
<H4>First line indentation</H4>
<P>
The <TT>Indent</TT> rule is used to specify the indentation of the first line
of the elements broken into lines by the <TT>Line</TT> function. The
indentation determines how far the first line of the element is shifted with
respect to the other lines of the same element. It can be specified as a
constant or by inheritance. The constant value is a positive integer (shifted
to the right; the sign is optional), a negative integer (shifted to the left)
or zero (no shift). All available <A href="#distunits">units</A> can be
used.</P>
<P>
Indentation can be defined for any box, regardless of whether the box is line
broken, and transmitted by inheritance to elements that are line broken. The
size of the indentation is specified in the same manner as the <A
href="#linespacing">line spacing</A>.</P>
<PRE>
'Indent' ':' DistOrInherit
</PRE>
</DIV>
<DIV class="subsubsection">
<H4>Alignment</H4>
<P>
The alignment style of the lines constructed during line breaking is defined
by the <TT>Adjust</TT> rule. The alignment value can be a constant or
inherited. A constant value is specified by a keyword:</P>
<UL>
<LI><TT>Left</TT>: at the left edge,
<LI><TT>Right</TT>: at the right edge,
<LI><TT>VMiddle</TT>: centered
<LI><TT>LeftWithDots</TT>: at the left edge with a dotted line filling out the
last line up to the right edge of the line breaking box.
</UL>
<P>
An inherited value can only be the same as that of the reference box and is
specified by a kinship keyword followed by an equals sign.</P>
<PRE>
'Adjust' ':' AlignOrInherit
AlignOrInherit = Kinship '=' / Alignment .
Alignment = 'Left' / 'Right' / 'VMiddle' /
'LeftWithDots' .
</PRE>
</DIV>
<DIV class="subsubsection">
<H4>Justification</H4>
<P>
The <TT>Justify</TT> rule indicates whether the lines contained in the box and
produced by a <TT>Line</TT> rule should be extended horizontally to occupy the
entire width of their enclosing box. The first and last lines are treated
specially: the position of the beginning of the first line is fixed by the
<TT>Indent</TT> rule and last line is not extended. The justification
parameter defined by this rule takes a boolean value, which can be a constant
or inherited. A constant boolean value is expressed by either the
<TT>Yes</TT> or the <TT>No</TT> keyword. An inherited value can only be the
same as that of the reference box and is specified by a kinship keyword
followed by an equals sign.</P>
<PRE>
'Justify' ':' BoolInherit
BoolInherit = Boolean / Kinship '=' .
Boolean ='Yes' / 'No' .
</PRE>
<P>
When the lines are justified, the alignment parameter specified in the
<TT>Adjust</TT> rule has no influence, other than on the last line produced.
This occurs because, when the other are extended to the limits of the box, the
alignment style is no longer perceptible.</P>
<BLOCKQUOTE class="example">
<P>
<STRONG>Example:</STRONG></P>
<P>
An important use of inheritance is to vary the characteristics of lines for an
element type (for example, Paragraph) according to the enclosing environment
(for example, Summary or Section), and thus obtain different line breaking
styles for the same elements when they appear in different environments. The
following rules specify that paragraphs inherit their alignment, justification,
and line spacing:</P>
<PRE>
Paragraph :
BEGIN
Justify : Enclosing = ;
LineSpacing : Enclosing = ;
Adjust : Enclosing =;
Line;
END;
</PRE>
<P>
If the alignment, justification, and line spacing of the Sectionand Summary
elements is fixed:</P>
<PRE>
Section :
BEGIN
Adjust : Left;
Justify : Yes;
LineSpacing : 1;
END;
Summary :
BEGIN
Adjust : VMiddle;
Justify : No;
LineSpacing : 1.3;
END;
</PRE>
<P>
then the paragraphs appearing in sections are justified with a simpleline
spacing while those appearing in summaries are centered and notjustified and
have a larger line spacing. These are nevertheless thevery same type of
paragraph defined in the logical structure schema.</P>
</BLOCKQUOTE>
</DIV>
<DIV class="subsubsection">
<H4><A name="hyphenaterule">Hyphenation</A></H4>
<P>
The <TT>Hyphenate</TT> rule indicates whether or not words should be broken by
hyphenation at the end of lines. It affects the lines produced by the
<TT>Line</TT> rule and contained in the box carrying the <TT>Hyphenate</TT>
rule.</P>
<P>
The hyphenation parameter takes a boolean value, which can be either constant
or inherited. A constant boolean value is expressed by either the
<TT>Yes</TT> or the <TT>No</TT> keyword. An inherited value can only be the
same as that of the reference box and is specified by a kinship keyword
followed by an equals sign.</P>
<PRE>
'Hyphenate' ':' BoolInherit
BoolInherit = Boolean / Kinship '=' .
Boolean = 'Yes' / 'No' .
</PRE>
</DIV>
<DIV class="subsubsection">
<H4><A name="inlinerule">Avoiding line breaking</A></H4>
<P>
The <TT>InLine</TT> rule is used to specify that a box that would otherwise
participate in line breaking asked for by the <TT>Line</TT> rule of an
enclosing box, instead avoids the line breaking process and positions itself
according to the <TT>HorizPos</TT> and <TT>VertPos</TT> rules that apply to
it. When the <TT>InLine</TT> rule applies to a box which would not be line
broken, it has no effect.</P>
<P>
The rule is expressed by the <TT>InLine</TT> keyword followed by a colon and
the keyword <TT>Yes</TT>, if the box should participate in line breaking, or
the keyword <TT>No</TT>, if it should not. This is the only form possible:
this rule cannot be inherited. Moreover, it can only appear in the rules of
the primary view and applies to all views defined in the presentation
schema.</P>
<PRE>
'InLine' ':' Boolean .
Boolean = 'Yes' / 'No' .
</PRE>
<BLOCKQUOTE class="example">
<P>
<STRONG>Example:</STRONG></P>
<P>
Suppose the structure schema defines a logical attribute
called <TT>New</TT> which is used to identify the passages in a document which
were recently modified. It would be nice to have the presentation schema make a
bar appear in the left margin next to each passage having
the <TT>New</TT> attribute. A new passage can be an entire element, such as a
paragraph or section, or it can be some words in the middle of a paragraph. To
produce the desired effect, the <TT>New</TT> attribute is given a creation rule
which generates a <TT>VerticalBar</TT> presentation box.</P>
<P>
When the <TT>New</TT> attribute is attached to a character string which is
inside a line broken element (inside a paragraph, for example), the bar is one
of the elements which participates in line breaking and it is placed normally
in the current line, at the end of the character string which has the
attribute. To avoid this, the <TT>InLine</TT> rule is used in the following
way:</P>
<PRE>
BOXES
VerticalBar:
BEGIN
Content: Graphics 'l';
HorizPos: Left = Root . Left;
VertPos: Top = Creator . Top;
Height: Bottom = Creator . Bottom;
Width: 1 pt;
InLine: No;
...
END;
...
ATTRIBUTES
Nouveau:
BEGIN
CreateAfter(VerticalBar);
END;
</PRE>
</BLOCKQUOTE>
</DIV>
</DIV>
<DIV class="subsection">
<H3><A name="breakcond">Page breaking and line breaking conditions</A></H3>
<P>
Pages are constructed by the editor in accordance with the model specified by
a <A href="#page"><TT>Page</TT> rule</A>. The page model describes only the
composition of the pages but does not give any rules for breaking different
element types across pages. Now, it is possible that certain elements must
not be cut by page breaks, while others can be cut anywhere. The
<TT>PageBreak</TT>, <TT>NoBreak1</TT>, and <TT>NoBreak2</TT> rules are used to
specify the conditions under which each element type can be cut.</P>
<P>
The <TT>PageBreak</TT> rule is used to indicate whether or not the box can be
cut during the construction of pages. If cutting is authorized, the box can
be cut, with one part appearing at the bottom of a page and the other part
appearing at the top of the next page. The rule is formed by the
<TT>PageBreak</TT> keyword followed by a colon and a constant boolean value
(<TT>Yes</TT> or <TT>No</TT>). This is the only form possible: this rule
cannot be inherited. Moreover, it can only appear in the rules of the primary
view and applies to all views defined in the presentation schema.</P>
<P>
Whether objects can be cut by line breaks can be controlled in a similar way
using the <TT>LineBreak</TT> rule. This rule allows the specification of
whether or not the box can be cut during the construction of lines. If
cutting is authorized, the box can be cut, with one part appearing at the end
of a line and the other part appearing at the beginning of the next line. The
rule is formed by the <TT>LineBreak</TT> keyword followed by a colon and a
constant boolean value (<TT>Yes</TT> or <TT>No</TT>). This is the only form
possible: this rule cannot be inherited. Moreover, it can only appear in the
rules of the primary view and applies to all views defined in the presentation
schema.</P>
<PRE>
'PageBreak' ':' Boolean .
'LineBreak' ':' Boolean .
Boolean = 'Yes' / 'No' .
</PRE>
<P>
When a box can be cut by a page break, it is possible that a page break will
fall an inappropriate spot, creating, for example, a widow or orphan, or
separating the title of a section from the first paragraph of the section. The
<TT>NoBreak1</TT> and <TT>NoBreak2</TT> rules are used to avoid this. They
specify that the box of the element type to which they apply cannot be cut
within a certain zone above (<TT>NoBreak1</TT> rule) or below
(<TT>NoBreak2</TT> rule). These two rules specify the height of the zones in
which page breaks are prohibited.</P>
<P>
The <TT>NoBreak1</TT> and <TT>NoBreak2</TT> rules give the height of the zone
in which page breaking is prohibited. The height is given as a constant value
using any of the <A href="#distunits">available units</A>, absolute or
relative. The value may not be inherited.</P>
<PRE>
'NoBreak1' ':' AbsDist .
'NoBreak2' ':' AbsDist .
</PRE>
<BLOCKQUOTE class="example">
<P>
<STRONG>Example:</STRONG></P>
<P>
The following rules prevent widows and orphans in a paragraph:</P>
<PRE>
Paragraph :
BEGIN
NoBreak1 : 2;
NoBreak2 : 2;
END;
</PRE>
<P>
This rule prevents a section title from becoming separated from the first
paragraph of the section by prohibiting page breaks at the beginning of the
section rule:</P>
<PRE>
Section :
NoBreak1 : 1.5 cm;
</PRE>
<P>
Finally, this rule prevents a figure from being page broken in any way:</P>
<PRE>
Figure :
PageBreak : No;
</PRE>
</BLOCKQUOTE>
<P>
The Thot editor constructs the document images displayed on the screen
dynamically. As the user moves in the document or makes the document scroll
in a window, the editor constructs the image to be displayed in little bits,
filling the gaps which are produced in the course of these operations. It
stops filling in the image when an element reaches the edge of the window in
which the gap appears. If the appearance of the document is complex, it is
possible that the image in incomplete, even though the edge of the window was
reached. For example, an element might need to be presented to the side of
the last element displayed, but its image was not constructed. The user will
not know whether the element is really absent or if its image has simply not
been constructed.</P>
<P>
The <TT>Gather</TT> rule is used to remedy this problem. When the rule
<TT>Gather : Yes;</TT> is associated with an element type, the image of such
elements is constructed as a block by the editor: it is never split up.</P>
<P>
The <TT>Gather</TT> rule may not appear in the <A
href="#defaultpresrules">default rules</A>. Elements which do not have the
<TT>Gather</TT> rule are considered susceptible to being split up during
display. Thus, it is not necessary to use the <TT>Gather : No;</TT> form.
This rule must be used prudently and only for those elements which truly need
it. If used incorrectly, it can pointlessly increase the size of the image
constructed by the editor and lead to excessive memory consumption by the
editor.</P>
<P>
Like the <TT>PageBreak</TT> and <TT>LineBreak</TT> rules, the <TT>Gather</TT>
rule can only appear in rules of the primary view and applies to all views
defined in the presentation schema.</P>
<PRE>
'Gather' ':' Boolean .
</PRE>
</DIV>
<DIV class="subsection">
<H3><A name="visib">Visibility</A></H3>
<P>
The visibility parameter is used to control which elements should or should
not be displayed, based on context. An element can have different
visibilities in different views. If an element's visibility is zero for a
view, that element is not displayed in that view and does not occupy any space
(its extents are zero).</P>
<P>
Visibility takes non-negative integer values (positive or zero). If values
greater than 1 are used, they allow the user to choose a degree of visibility
and, thus, to see only those boxes whose visibility parameter exceeds a
certain threshold. This gives the user control over the granularity of the
displayed pictures.</P>
<P>
The visibility parameter can be defined as a constant or by inheritance. If
defined by inheritance, it cannot be based on the value of the next or
previous box. Visibility can only be inherited from above.</P>
<P>
If it is a numeric attribute's presentation rule, the visibility can be
specified by the attribute's name, in which case the value of the attribute is
used.</P>
<PRE>
'Visibility' ':' NumberInherit
NumberInherit = Integer / AttrID / Inheritance .
Integer = NUMBER .
</PRE>
<BLOCKQUOTE class="example">
<P>
<STRONG>Example:</STRONG></P>
<P>
Suppose that only <TT>Formula</TT> elements should be displayed in
the <TT>MathView</TT> view. Then, the default rules should include:</P>
<PRE>
DEFAULT
IN MathView Visibility:0;
</PRE>
<P>
which makes all elements invisible in the <TT>MathView</TT> view. However, the
<TT>Formula</TT> element also has a <TT>Visibility</TT> rule:</P>
<PRE>
Formula :
IN MathView Visibility:5;
</PRE>
<P>
which makes formulas, and only formulas, visible.</P>
</BLOCKQUOTE>
</DIV>
<DIV class="subsection">
<H3>Character style parameters</H3>
<P>
Four parameters are used to determine which characters are used to display
text. They are size, font, style, and underlining.</P>
<DIV class="subsubsection">
<H4>Character size</H4>
<P>
The size parameter has two effects. First, it is used to specify the actual
size and distance units for boxes defined in <A href="#distunits">relative
units</A>. Second, it defines the size of the characters contained in the
box.</P>
<P>
As a distance or length, the size can be expressed in abstract or absolute
units. It can also be inherited. If it is not inherited, it is expressed
simply as an integer followed by the <TT>pt</TT> keyword, which indicates that
the size is expressed in typographer's points. The absence of the <TT>pt</TT>
keyword indicates that it is in abstract units in which the value 1 represents
the smallest size while the value 16 is the largest size. The relationship
between these abstract sizes and the real character sizes is controlled by a
table which can be modified statically or even dynamically during the
execution of the Thot editor.</P>
<P>
If it is a numeric attribute's presentation rule, the value of the size
parameter can be specified by the attribute's name, in which case the value of
the attribute is used.</P>
<P>
<STRONG>Note:</STRONG> the only unit available for defining an absolute size
is the typographer's point. Centimeters and inches may not be used.</P>
<P>
If the size is inherited, the rule must specify the relative from which to
inherit and any difference from that relative's value. The difference can be
expressed in either typographer's points or in abstract units. The maximum or
minimum size can also be specified, but without specifying the type of unit:
it is the same as was specified for the difference.</P>
<P>
In a numeric attribute's presentation rule, the difference in size can be
indicated by the attribute's name, which means that the attribute's value
should be used as the difference. The attribute can also be used as the
minimum or maximum size.</P>
<PRE>
'Size' ':' SizeInherit
SizeInherit = SizeAttr [ 'pt' ] /
Kinship InheritedSize .
InheritedSize ='+' SizeAttr [ 'pt' ]
[ 'Max' MaxSizeAttr ] /
'-' SizeAttr [ 'pt' ]
[ 'Min' MinSizeAttr ] /
'=' .
SizeAttr = Size / AttrID .
Size = NUMBER .
MaxSizeAttr = MaxSize / AttrID .
MaxSize = NUMBER .
MinSizeAttr = MinSize / AttrID .
MinSize = NUMBER .
</PRE>
<BLOCKQUOTE class="example">
<P>
<STRONG>Example:</STRONG></P>
<P>
The rule</P>
<PRE>
Size : Enclosing - 2 pt Min 7;
</PRE>
<P>
states that the character size is 2 points less than that of the enclosing box,
but that it may not be less than 7 points, whatever the enclosing box's
value.</P>
<P>
The following rules make the text of a report be displayed with medium-sized
characters (for example, size 5), while the title is displayed with larger
characters and the summary is displayed with smaller characters:</P>
<PRE>
Report :
Size : 5;
Title :
Size : Enclosing + 2;
Summary :
Size : Enclosing - 1;
</PRE>
<P>
Thus, the character sizes in the entire document can be changed bychanging the
size parameter of the Report element, while preservingthe relationships
between the sizes of the different elements.</P>
</BLOCKQUOTE>
</DIV>
<DIV class="subsubsection">
<H4><A name="style">Font and character style</A></H4>
<P>
The <TT>Font</TT> rule determines the font family to be used to display the
characters contained in the box, while the <TT>Style</TT> rule determines
their style. Thot recognizes three character fonts (Times, Helvetica, and
Courier) and six styles: Roman, Italics, Bold, BoldItalics, Oblique, and
BoldOblique.</P>
<P>
The font family and style can specified by a named constant or can be
inherited. For the name of the font family only the first character is
used.</P>
<P>
Only identical inheritance is allowed: the box takes the same font or style as
the box from which it inherits. This is indicated by an equals sign after the
kinship specification.</P>
<BLOCKQUOTE class="example">
<P>
<STRONG>Example:</STRONG></P>
<P>
To specify that the summary uses the font family of the rest of the document,
but in the italic style, the following rules are used:</P>
<PRE>
Summary :
BEGIN
Font : Enclosing =;
Style : Italics;
END;
</PRE>
</BLOCKQUOTE>
</DIV>
<DIV class="subsubsection">
<H4><A name="underline">Underlining</A></H4>
<P>
The <TT>Underline</TT> rule is used to specify if the characters contained in
a box should have lines drawn on or near them. There are four underlining
styles: <TT>Underlined</TT>, <TT>Overlined</TT>, <TT>CrossedOut</TT>, and
<TT>NoUnderline</TT>. The <TT>Thickness</TT> rule specifies the thickness of
the line, <TT>Thin</TT> or <TT>Thick</TT>.</P>
<P>
As with font family and style, only identical inheritance is allowed: the box
has the same underlining type as the box from which it inherits the value.
This is indicated by an equals sign after the kinship specification.</P>
<PRE>
'Underline' ':' UnderLineInherit /
'Thickness' ':' ThicknessInherit /
UnderLineInherit = Kinship '=' / 'NoUnderline' /
'Underlined' /
'Overlined' / 'CrossedOut' .
ThicknessInherit = Kinship '=' / 'Thick' / 'Thin' .
</PRE>
</DIV>
</DIV>
<DIV class="subsection">
<H3>Stacking order</H3>
<P>
The <TT>Depth</TT> rule is used to define the stacking order of terminal boxes
when multiple boxes at least partially overlap. This rule defines how the
depth parameter, which is zero or a positive integer, is calculated. The
depth parameter has a value for all boxes. For terminal boxes in the
structure and for presentation boxes, the depth value is used during display
and printing: the boxes with the lowest value overlap those with higher
depths. For non-terminal boxes, the depth is not interpreted during display,
but it is used to calculate the depth of terminal boxes by inheritance.</P>
<P>
Like most other rules, the depth rule is defined in the <A
href="#defaultpresrules">default rules</A> of each presentation schema. Thus,
there is always a depth value, even when it is not necessary because there is
no overlapping. To avoid useless operations, a zero value can be given to the
depth parameter, which signifies that overlapping is never a problem.</P>
<P>
The depth rule has the same form as the <A href="#visib">visibility rule</A>.
It can be defined by inheritance or by a constant numeric value. When the rule
is attached to a numeric attribute, it can take the value of that
attribute.</P>
<PRE>
'Depth' ':' NumberInherit
</PRE>
<BLOCKQUOTE class="example">
<P>
<STRONG>Example:</STRONG></P>
<P>
For a purely textual document, in which overlapping never poses a problem, a
single default <TT>Depth</TT>rule in the presentation schema is sufficient:</P>
<PRE>
DEFAULT
Depth : 0;
...
</PRE>
<P>
To make the text of examples appear on a light blue background, a presentation
box is defined:</P>
<PRE>
BOXES
BlueBG :
BEGIN
Content : Graphics 'R';
Background : LightBlue3;
FillPattern: backgroundcolor;
Depth : 2;
...
END;
</PRE>
<P>
and is created by the <TT>Example</TT> element, which has the rules:</P>
<PRE>
RULES
Example :
BEGIN
CreateFirst (BlueBG);
Depth : 1;
...
END;
</PRE>
<P>
In this way, the text of an example (if it inherits its depth from
itsancestor) will be superimposed on a light blue background, and not
thereverse).</P>
</BLOCKQUOTE>
</DIV>
<DIV class="subsection">
<H3>Line Style</H3>
<P>
The <TT>LineStyle</TT> rule determines the style of line which should be used
to draw all the elements contained in the box. The line style can be
indicated by a name (<TT>Solid</TT>, <TT>Dashed</TT>, <TT>Dotted</TT>) or it
can be inherited. Only elements of the graphic base type are affected by this
rule, but it can be attached to any box and transmitted by inheritance to the
graphic elements.</P>
<P>
Only identical inheritance is allowed: the box takes the same line style as
the box from which it inherits. This is indicated by an equals sign after the
kinship specification.</P>
<PRE>
'LineStyle' ':' LineStyleInherit
LineStyleInherit = Kinship '=' /
'Solid' / 'Dashed' / 'Dotted' .
</PRE>
<BLOCKQUOTE class="example">
<P>
<STRONG>Example:</STRONG></P>
<P>
To specify that, in Figures, the graphical parts should be drawn in solid
lines, the Figure element is given a rule using the <TT>Solid</TT> name:</P>
<PRE>
Figure :
LineStyle : Solid;
</PRE>
<P>
and the elements composing figures are given an inheritance rule:</P>
<PRE>
LineStyle : Enclosing =;
</PRE>
</BLOCKQUOTE>
</DIV>
<DIV class="subsection">
<H3>Line thickness</H3>
<P>
The <TT>LineWeight</TT> rule determines the thickness of the lines of all
graphical elements which appear in the box, no matter what their line style.
Line thickness can be specified by a constant value or by inheritance. A
constant value is a positive number followed by an optional unit specification
(which is absent when using relative units). All available <A
href="#distunits">distance units</A> can be used. Line thickness is expressed
in the same way as <A href="#linespacing">line spacing</A>.</P>
<PRE>
'LineWeight' ':' DistOrInherit
</PRE>
<P>
Only elements of the graphic base type are affected by this rule, but it can
be attached to any box and transmitted by inheritance to the graphic
elements.</P>
<BLOCKQUOTE class="example">
<P>
<STRONG>Example:</STRONG></P>
<P>
To specify that, in Figures, the graphical parts should be drawn with lines 0.3
pt thick, the Figure element is given this rule:</P>
<PRE>
Figure :
LineWeight : 0.3 pt;
</PRE>
<P>
and the elements composing figures are given an inheritance rule:</P>
<PRE>
LineWeight : Enclosing =;
</PRE>
</BLOCKQUOTE>
</DIV>
<DIV class="subsection">
<H3><A name="pattern">Fill pattern</A></H3>
<P>
The <TT>FillPattern</TT> rule determines the pattern used to fill closed
graphical elements (circles, rectangles, etc.) which appear in the box. This
pattern can be indicated by a named constant or by inheritance. The named
constant identifies one of the patterns available in Thot. The names of the
available patterns are: nopattern, foregroundcolor, backgroundcolor, gray1,
gray2, gray3, gray4, gray5, gray6, gray7, horiz1, horiz2, horiz3, vert1,
vert2, vert3, left1, left2, left3, right1, right2, right3, square1, square2,
square3, lozenge, brick, tile, sea, basket.</P>
<P>
Like the other rules peculiar to graphics, <TT>LineStyle</TT> and
<TT>LineWeight</TT>, only elements of the graphic base type are affected by
the <TT>FillPattern</TT> rule, but the rule can be attached to any box and
transmitted by inheritance to the graphic elements. As with the other rules
specific to graphics, only identical inheritance is allowed.</P>
<P>
The <TT>FillPattern</TT> rule can also be used to determine whether or not
text characters, symbols and graphics should be colored. For these element
types (text, symbols, and graphics), the only valid values are nopattern,
foregroundcolor, and backgroundcolor. When <TT>FillPattern</TT> has the value
<TT>backgroundcolor</TT>, text characters, symbols, and bitmaps are given the
color specified by the <A href="#colors"><TT>Background</TT> rule</A> which
applies to these elements. When <TT>FillPattern</TT> has the value
<TT>foregroundcolor</TT>, these same elements are given the color specified by
the <A href="#colors"><TT>Foreground</TT> rule</A> which applies to these
elements. In all other case, text characters are not colored.</P>
<PRE>
'FillPattern' ':' NameInherit
</PRE>
<BLOCKQUOTE class="example">
<P>
<STRONG>Example:</STRONG></P>
<P>
To specify that, in Figures, the closed graphical elements should be filled
with a pattern resembling a brick wall, the Figure element is given this
rule:</P>
<PRE>
Figure :
FillPattern : brick;
</PRE>
<P>
and the elements composing figures are given an inheritance rule:</P>
<PRE>
FillPattern : Enclosing =;
</PRE>
</BLOCKQUOTE>
</DIV>
<DIV class="subsection">
<H3><A name="colors">Colors</A></H3>
<P>
The <TT>Foreground</TT> and <TT>Background</TT> rules determine the foreground
and background colors of the base elements which appear in the box. These
colors cancan be specified with a named constant or by inheritance. The named
constants specify one of the available colors in Thot. The available color
names can be found in the file <TT>thot.color</TT>.</P>
<P>
In contrast to the preceding rules, the color rules affect all base elements
the same way, no matter what their type (text, graphics, pictures, symbols),
but they only affect base elements. The color rules can nevertheless be
associated with any box and can be transmitted to the base elements by
inheritance. Like the preceding rules, only inheritance of the same value is
allowed.</P>
<PRE>
'Foreground' ':' NameInherit
'Background' ':' NameInherit
</PRE>
<P>
<STRONG>Note:</STRONG> text colors only appear for text elements whose <A
href="#pattern">fill pattern</A> does not prevent the use of color.</P>
<BLOCKQUOTE class="example">
<P>
<STRONG>Example:</STRONG></P>
<P>
To specify that, in Figures, everything must be drawn in blue on a background
of yellow, the Figure element isgiven these rules:</P>
<PRE>
Figure :
BEGIN
Foreground : Blue;
Background : Yellow;
Fillpattern : backgroundcolor;
END;
</PRE>
<P>
and the elements composing figures are given inheritance rules:</P>
<PRE>
Foreground : Enclosing =;
Background : Enclosing =;
FillPattern : Enclosing =;
</PRE>
</BLOCKQUOTE>
</DIV>
<DIV class="subsection">
<H3><A name="content">Presentation box content</A></H3>
<P>
The <TT>Content</TT> rule applies to presentation boxes. It indicates the
content given to a box. This content is either a variable's value or a
constant value. In the special case of <A href="#page">header or footer
boxes</A>, the content can also be a structured element type.</P>
<P>
If the content is a constant, it can be specified, as in a variable
declaration, either by the name of a constant declared in the <TT>CONST</TT>
section or by direct specification of the type and value of the box's
content.</P>
<P>
Similarly, if it is a variable, the name of a variable declared in
<TT>VAR</TT> section can be given or the variable may be defined within
parentheses. The content inside the parentheses has the same syntax as a <A
href="#variables">variable declaration</A>.</P>
<P>
When the content is a structured element type, the name of the element type is
given after the colon. In this case, the box's content is all elements of
the named type which are designated by references which are part of the page
on which the header or footer with this <TT>Content</TT> rule appears. Only
associated elements can appear in a <TT>Content</TT> rule and the structure
must provide references to these elements. Moreover, the box whose content
they are must be a header or footer box generated by a page box of the primary
view.</P>
<PRE>
'Content' ':' VarConst
VarConst = ConstID / ConstType ConstValue /
VarID / '(' FunctionSeq ')' /
ElemID .
</PRE>
<P>
A presentation box can have only one <TT>Content</TT> rule, which means that
the content of a presentation box cannot vary from view to view. However, such
an effect can be achieved by creating several presentation boxes, each with
different content and visible in different views.</P>
<P>
The <TT>Content</TT> rule also applies to elements defined as references in
the structure schema. In this case, the content defined by the rule must be
a constant. It is this content which appears on the screen or paper to
represent references of the type to which the rule applies. A reference can
have a <TT>Content</TT> rule or a <A href="#copyrule"><TT>Copy</TT> rule</A>
for each view. If neither of these rules appears, the reference is displayed
as <TT>[*]</TT>, which is equivalent to the rule:</P>
<PRE>
Content: Text '[*]';
</PRE>
<BLOCKQUOTE class="example">
<P>
<STRONG>Example:</STRONG></P>
<P>
The content of the presentation box created to make the chapter number and
section number appear before each section title can be defined by:</P>
<PRE>
BOXES
SectionNumBox :
BEGIN
Content : NumSection;
...
END;
</PRE>
<P>
if the <TT>NumSection</TT>variable has been defined in the variable definition
section of the presentation schema. Otherwise the <TT>Content</TT> would be
written:</P>
<PRE>
BOXES
SectionNumBox :
BEGIN
Content : (VALUE (ChapterCtr, Roman) TEXT '.'
VALUE (SectionCtr, Arabic));
...
END;
</PRE>
<P>
To specify that a page footer should contain all elements of the <TT>Note</TT>
type are referred to in the page, the following rule is written:</P>
<PRE>
BOXES
NotesFooterBox :
BEGIN
Content : Note;
...
END;
</PRE>
<P>
<TT>Note</TT>is defined as an associated element in the structure schemaand
NotesFooterBox is created by a page box of the primary view.</P>
</BLOCKQUOTE>
</DIV>
<DIV class="subsection">
<H3><A name="creation">Presentation box creation</A></H3>
<P>
A creation rule specifies that a presentation box should be created when an
element of the type to which the rule is attached appears in the document.</P>
<P>
A keyword specifies the position, relative to the creating box, at which the
created box will be placed in the structure:</P>
<DL>
<DT><TT>CreateFirst</TT></DT>
<DD>specifies that the box should be created as the first box of the next lower
level, before any already existing boxes, and only if the beginning of the
creating element is visible;
</DD>
<DT><TT>CreateLast</TT></DT>
<DD>specifies that the box should be created as the last box of the next lower
level, after any existing boxes, and only if the end of the creating element is
visible;
</DD>
<DT><TT>CreateBefore</TT></DT>
<DD>specifies that the box should be created before the creating box, on the
same level as the creating box, and only if the beginning of the creating
element is visible;
</DD>
<DT><TT>CreateAfter</TT></DT>
<DD>specifies that the box should be created after the creating box, on the
same level as the creating box, and only if the beginning of the creating
element is visible;
</DD>
<DT><TT>CreateEnclosing</TT></DT>
<DD>specifies that the box should be created at the upper level relatively to
the creating box, and that it must contain that creating box and all
presentation boxes created by the same creating box.
</DD>
</DL>
<P>
This keyword can be followed by the <TT>Repeated</TT> keyword to indicate that
the box must be created for each part of the creating element. These parts
result from the division of the element by page breaks or column changes. If
the <TT>Repeated</TT> keyword is missing, the box is only created for the
first part of the creating element (<TT>CreateFirst</TT> and
<TT>CreateBefore</TT> rules) or for the last part (<TT>CreateLast</TT> and
<TT>CreateAfter</TT> rules).</P>
<P>
The type of presentation to be created is specified at the end of the rule
between parentheses.</P>
<P>
Creation rules cannot appear in the <A href="#defaultpresrules">default
presentation rules</A>. The boxes being created should have a
<TT>Content</TT> rule which indicates their <A
href="#content">content</A>.</P>
<P>
Creation rules can only appear in the block of rules for the primary view;
creation is provoked by a document element for all views. However, for each
view, the presentation box is only created if the creating element is itself a
box in the view. Moreover, the visibility parameter of the presentation box
can be adjusted to control the creation of the box on a view-by-view
basis.</P>
<PRE>
Creation '(' BoxID ')'
Creation = Create [ 'Repeated' ] .
Create ='CreateFirst' / 'CreateLast' /
'CreateBefore' / 'CreateAfter' /
'CreateEnclosing' .
</PRE>
<BLOCKQUOTE class="example">
<P>
<STRONG>Example:</STRONG></P>
<P>
Let us define an object type, called Table, which is composed of a sequence of
columns, all having the same fixed width, where the columns are separated by
vertical lines. There is a line to the left of the first column and one to the
right of the last. Each column has a variable number of cells, placed one on
top of the other and separated by horizontal lines. There are no horizontal
lines above the first cell or below the last cell. The text contained in
each cell is broken into lines and these lines are centered horizontally in the
cell. The logical structure of this object is defined by:</P>
<PRE>
Table = LIST OF (Column);
Column = LIST OF (Cell = Text);
</PRE>
<DIV class="figure">
<HR>
<PRE>
| | | |
| xx xxxx xxxx |x xxxx xxx xxxxx| x xxx x xxx |
| xxx xxx xxxx x | x xx x xxx | xxxxx xxxx xx |
| xxxxx xxxx |----------------| xxx xxxxx x |
| xxxxx xxx xxxx | xxxx xx xx xxx | xx xx |
| xxx xxxx x xxx | xxxx x xxx x |---------------|
|----------------| xxx xxxx xxxxx | xxxxx xxxxx |
| xxx xxx xxxxxx |----------------| xxx xxxx xxxx |
| xxxx xxxx xx | xxxx xx x xx | xxx xx x xx |
|----------------| xxx xxxxx xxxx | xxxx xxxx xxx |
| xxxxx xxx xxxx | xxxx xx x xx | xxxxx xxx |
|xxxx xx x xxxxxx| xxxx xx xxxxxx | xxxxx xxxxx |
</PRE>
<P align=center>
<EM><A name="table">The design of a table</A></EM></P>
<HR>
</DIV>
<P>
The presentation of the table should resemble the design of the above <A
href="#table">figure</A>. It is defined by the following presentation schema
fragment:</P>
<PRE>
BOXES
VertLine : BEGIN
Width : 0.3 cm;
Height : Enclosing . Height;
VertPos : Top = Enclosing . Top;
HorizPos : Left = Previous . Right;
Content : Graphics 'v';
END;
HorizLine: BEGIN
Width : Enclosing . Width;
Height : 0.3 cm;
VertPos : Top = Previous . Bottom;
HorizPos : Left = Enclosing . Left;
Content : Graphics 'h';
END;
RULES
Column : BEGIN
CreateBefore (VertLine);
IF LAST CreateAfter (VertLine);
Width : 2.8 cm;
Height : Enclosed . Height;
VertPos : Top = Enclosing . Top;
HorizPos : Left = Previous . Right;
END;
Cell : BEGIN
IF NOT FIRST CreateBefore (HorizLine);
Width : Enclosing . Width;
Height : Enclosed . Height;
VertPos : Top = Previous . Bottom;
HorizPos : Left = Enclosing . Left;
Line;
Adjust : VMiddle;
END;
</PRE>
<P>
It is useful to note that the horizontal position rule of the first vertical
line will not be applied, since there is no preceding box. In this case, the
box is simply placed on the left side of the enclosing box.</P>
</BLOCKQUOTE>
</DIV>
<DIV class="subsection">
<H3><A name="page">Page layout</A></H3>
<P>
The page models specified in the <TT>Page</TT> rule are defined by boxes
declared in the <TT>BOXES</TT> section of the presentation schema. Pages are
not described as frames which will be filled by the document's text, but as
element are inserted in the flow of the document and which mark the page
breaks. Each of these page break elements contains presentation boxes which
represent the footer boxes of a page followed by header boxes of the next
page. The page box itself is the simple line which separates two pages on the
screen. Both the footer and header boxes placed themselves with respect to
this page box, with the footer being placed above it and the header boxes
being placed above it.</P>
<P>
The boxes created by a page box are headers and footers and can only place
themselves vertically with respect to the page box itself (which is in fact
the separation between two pages). Besides, it is their vertical position
rule which determines whether they are header or footer boxes. Header and
footer boxes must have an explicit vertical position rule (they must not use
the default rule).</P>
<P>
Footer boxes must have an absolute height or inherit the height of their
contents:</P>
<PRE>
Height : Enclosed . Height;
</PRE>
<P>
A page box must have height and width rules and these two rules must be
specified with constant values, expressed in centimeters, inches, or
typographer's points. These two rules are interpreted in a special way for
page boxes: they determine the width of the page and the vertical distance
between two page separators, which is the height of the page and its header
and footer together.</P>
<P>
A page box should also have vertical and horizontal position rules and these
two rules should specify the position on the sheet of paper of the rectangle
enclosing the page's contents. These two rules must position the upper left
corner of the enclosing rectangle in relation to the upper left corner of the
sheet of paper, considered to be the enclosing element. In both rules,
distances must be expressed in fixed units: centimeters (<TT>cm</TT>), inches
(<TT>in</TT>), or typographer's points (<TT>pt</TT>). Thus, rules similar to
the following should be found in the rules for a page box:</P>
<PRE>
BOXES
ThePage :
BEGIN
VertPos : Top = Enclosing . Top + 3 cm;
HorizPos : Left = Enclosing . Left + 2.5 cm;
Width : 16 cm;
Height : 22.5 cm;
END;
</PRE>
<P>
When a document must be page broken, the page models to be constructed are
defined in the <TT>BOXES</TT> section of the presentation schema by declaring
page boxes and header and footer boxes. Also, the <TT>Page</TT> rule is used
to specify to which parts of the document and to which views each model should
be applied.</P>
<P>
The <TT>Page</TT> rule has only one parameter, given between parentheses after
the <TT>Page</TT> keyword. This parameter is the name of the box which must
serve as the model for page construction. When a <TT>Page</TT> rule is
attached to an element type, each time such an element appears in a document,
a page break takes place and the page model indicated in the rule is applied
to all following pages, until reaching the next element which has a
<TT>Page</TT> rule.</P>
<P>
The <TT>Page</TT> rule applies to only one view; if it appears in the primary
view's block of rules, a <TT>Page</TT> rule applies only to that view. Thus,
different page models can be defined for the full document and for its table
of contents, which is another view of the same document. Some views can be
specified with pages, and other views of the same document can be specified
without pages.</P>
<PRE>
'Page' '(' BoxID ')'
</PRE>
</DIV>
<DIV class="subsection">
<H3><A name="copyrule">Box copies</A></H3>
<P>
The <TT>Copy</TT> rule can be used for an element which is defined as a
reference in the structure schema. In this case, the rule specified, between
parenthesis, thee name of the box (declared in the <TT>BOXES</TT> section)
which must be produced when this reference appears in the structure of a
document. The box produced is a copy (same contents, but possible different
presentation) of the box type indicated by the parameter between parentheses,
and which is in the element designated by the reference. The name of a box
can be replaced by type name. Then what is copied is the contents of the
element of this type which is inside the referenced element.</P>
<P>
Whether a box name or type name is given, it may be followed by the name of a
structure schema between parentheses. This signifies that the box or type is
defined in the indicated structure schema and not in the structure schema with
which the rule's presentation schema is associated.</P>
<P>
The <TT>Copy</TT> rule can also be applied to a presentation box. If the
presentation box was created by a reference attribute, the rule is applied as
in the case of a reference element: the contents of the box having the
<TT>Copy</TT> rule are based on the element designated by the reference
attribute. For other presentation boxes, the <TT>Copy</TT> rule takes a type
name parameter which can be followed, between parentheses, by the name of the
structure schema in which the type is defined, if it is not defined in the
same schema. The contents of the box which has this rule are a copy of the
element of this type which is in the element creating the presentation box, or
by default, the box of this type which precedes the presentation box. This
last facility is used, for example, to define the running titles in headers or
footers.</P>
<PRE>
'Copy' '(' BoxTypeToCopy ')' .
BoxTypeToCopy = BoxID [ ExtStruct ] /
ElemID [ ExtStruct ] .
ExtStruct = '(' ElemID ')' .
</PRE>
<P>
Like the creation rules, the <TT>Copy</TT> rule cannot appear in the <A
href="#defaultpresrules">default presentation rules</A>. Moreover, this rule
can only appear in the primary view's block of rules; the copy rule is applied
to all views.</P>
<BLOCKQUOTE class="example">
<P>
<STRONG>Example:</STRONG></P>
<P>
If the following definitions are in the structure schema:</P>
<PRE>
Body = LIST OF (Chapter =
BEGIN
ChapterTitle = Text;
ChapterBody = SectionSeq;
END);
RefChapter = REFERENCE (Chapter);
</PRE>
<P>
then the following presentation rules (among many other rules in
the presentation schema) can be specified:</P>
<PRE>
COUNTERS
ChapterCtr : RANK OF Chapter;
BOXES
ChapterNumber :
BEGIN
Content : (VALUE (ChapterCtr, URoman));
...
END;
RULES
Chapter :
BEGIN
CreateFirst (ChapterNumber);
...
END;
RefChapter :
BEGIN
Copy (ChapterNumber);
...
END;
</PRE>
<P>
which makes the number of the chapter designated by the referenceappear in
uppercase roman numerals, in place of the reference to achapter itself.
Alternatively, the chapter title can be made toappear in place of the
reference by writing this <TT>Copy</TT>rule:</P>
<PRE>
Copy (ChapterTitle);
</PRE>
<P>
To define a header box, named <TT>RunningTitle</TT>, which contains the title
of the current chapter, the box's contents are defined in this way:</P>
<PRE>
BOXES
RunningTitle :
Copy (ChapterTitle);
</PRE>
</BLOCKQUOTE>
</DIV>
</DIV>
<HR>
</DIV>
<DIV class="chapter">
<H1>The T language</H1>
<DIV class="section">
<H2>Document translation</H2>
<P>
Because of its document model, Thot can produce documents in a high-level
abstract form. This form, called the <EM>canonical form</EM> is specific to
Thot; it is well suited to the editor's manipulations, but it does not
necessarily suit other operations which might be applied to documents. Because
of this, the Thot editor offers the choice of saving documents in its own form
(the canonical form) or a format defined by the user. In the latter case, the
Thot document is transformed by the translation program. This facility can
also be used to export documents from Thot to systems using other
formalisms.</P>
<DIV class="subsection">
<H3>Translation principles</H3>
<P>
Document translation allows the export of documents to other systems which do
not accept Thot's canonical form. Translation can be used to export document
to source-based formatters like T<SUB><BIG>E</BIG></SUB>X,
L<SUP>A</SUP>T<SUB><BIG>E</BIG></SUB>X, and <TT>troff</TT>. It can also be
used to translate documents into interchange formats like SGML or HTML. To
allow the widest range of possible exports, Thot does not limit the choice of
translations, but rather allows the user to define the formalisms into which
documents can be translated.</P>
<P>
For each document or object class, a set of translation rules can be defined,
specifying how the canonical form should be transformed into a given
formalism. These translation rules are grouped into <EM>translation
schemas</EM>, each schema containing the rules necessary to translate a
generic logical structure (document or object structure) into a particular
formalism. The same generic logical structure can have several different
translation schemas, each defining translation rules for a different
formalism.</P>
<P>
Like presentation schemas, translation schemas are generic. Thus, they apply
to an entire object or document class and permit translation of all documents
or objects of that class.</P>
</DIV>
<DIV class="subsection">
<H3>Translation procedure</H3>
<P>
The translator works on the specific logical structure of the document being
translated. It traverses the primary tree of this logical structure in
pre-order and, at each node encountered, it applies the corresponding
translation rules defined in the translation schema. Translation can be
associated:</P>
<UL>
<LI>with element types defined in the structure schema,
<LI>with global or local attributes defined in the structure schema,
<LI>with specific presentation rules,
<LI>with the content of the leaves of the structure (characters, symbols and
graphical elements)
</UL>
<P>
Thus, for each node, the translator applies all rules associated with the
element type, all rules associated with each attribute (local or global)
carried by the element, and if the element is a leaf of the tree, it also
applies Translation rules for characters, symbols, or graphical elements,
depending on the type of the leaf.</P>
<P>
Rules associated with the content of leaves are different from all other
rules: they specify only how to translate character strings, symbols, and
graphical elements. All other rules, whether associated with element types,
with specific presentation rules or with attributes, are treated similarly.
These rules primarily allow:</P>
<UL>
<LI>generation of a text constant or variable before or after the contents of
an element,
<LI>modification of the order in which elements appear after translation,
<LI>removal of an element in the translated document,
<LI>and writing messages on the user's terminal during translation.
</UL>
</DIV>
</DIV>
<DIV class="section">
<H2>Translation definition language</H2>
<P>
Translation schemas are written in a custom language, called T, which is
described in the rest of this chapter. The grammar of T is specified using
the same <A href="#metalang">meta-language</A> as was used for the S and P
languages and the translation schemas are written using the same conventions
as the structure and presentation schemas. In particular, the keywords of the
T language (the stings between apostrophes in the following syntax rules) can
be written in any combination of upper-case and lower-case letters, but
identifiers created by the programmer must always be written in the same
way.</P>
<DIV class="subsection">
<H3>Organization of a translation schema</H3>
<P>
A translation schema is begun by the <TT>TRANSLATION</TT> keyword and is
terminated by the <TT>END</TT> keyword. The <TT>TRANSLATION</TT> keyword is
followed by the name of the generic structure for which a translation is being
defined and a semicolon. This name must be identical to the name which
appears after the <TT>STRUCTURE</TT> keyword in the corresponding structure
schema.</P>
<P>
After this declaration of the structure, the following material appears in
order:</P>
<UL>
<LI>the length of lines produced by the translation,
<LI>the character delimiting the end of the line,
<LI>the character string which the translator will insert if it must
line-break the translated text,
<LI>declarations of
<UL>
<LI>buffers,
<LI>counters,
<LI>constants,
<LI>variables,
</UL>
<LI>translation rules associated with element types,
<LI>translation rules associated with attributes,
<LI>translation rules associated with specific presentation rules,
<LI>translation rules associated with characters strings, symbols and
graphical elements.
</UL>
<P>
Each of these sections is introduced by a keyword followed by a sequence of
declarations. All of these sections are optional, expect for the translation
rules associated with element types. Many <TT>TEXTTRANSLATE</TT> sections can
appear, each defining the rules for translating character strings of a
particular alphabet.</P>
<PRE>
TransSchema ='TRANSLATION' ElemID ';'
[ 'LINELENGTH' LineLength ';' ]
[ 'LINEEND' CHARACTER ';' ]
[ 'LINEENDINSERT' STRING ';' ]
[ 'BUFFERS' BufferSeq ]
[ 'COUNTERS' CounterSeq ]
[ 'CONST' ConstSeq ]
[ 'VAR' VariableSeq ]
'RULES' ElemSeq
[ 'ATTRIBUTES' AttrSeq ]
[ 'PRESENTATION' PresSeq ]
< 'TEXTTRANSLATE' TextTransSeq >
[ 'SYMBTRANSLATE' TransSeq ]
[ 'GRAPHTRANSLATE' TransSeq ]
'END' .
</PRE>
</DIV>
<DIV class="subsection">
<H3><A name="linelength">Line length</A></H3>
<P>
If a <TT>LINELENGTH</TT> instruction is present after the structure
declaration, the translator divides the text it produces into lines, each line
having a length less than or equal to the integer which follows the
<TT>LINELENGTH</TT> keyword. This maximum line length is expressed as a
number of characters. The end of the line is marked by the character defined
by the <TT>LINEEND</TT> instruction. When the translator breaks the lines on
a space character in generated text, this space will be replaced by the
character string defined by the <TT>LINEENDINSERT</TT> instruction.</P>
<P>
If the <TT>LINEEND</TT> instruction is not defined then the linefeed character
(octal code 12) is used as the default line end character. If the
<TT>LINEENDINSERT</TT> instruction is not defined, the linefeed character is
inserted at the end of the produced lines. If there is no <TT>LINELENGTH</TT>
instruction, the translated text is not divided into lines. Otherwise, if the
translation rules generate line end marks, these marks remain in the
translated text, but the length of the lines is not controlled by the
translator.</P>
<PRE>
LineLength = NUMBER .
</PRE>
<BLOCKQUOTE class="example">
<P>
<STRONG>Example:</STRONG></P>
<P>
To limit the lines produced by the translator to a length of 80 characters, the
following rule is written at the beginning of the translation schema.</P>
<PRE>
LineLength 80;
</PRE>
</BLOCKQUOTE>
</DIV>
<DIV class="subsection">
<H3>Buffers</H3>
<P>
A buffer is a unit of memory managed by the translator, which can either
contain text read from the terminal during the translation (see the <A
href="#readrule"><TT>Read</TT> rule</A>), or the name of the last picture
(bit-map) encountered by the translator in its traversal of the document.
Remember the pictures are stored in files that are separate for the document
files and that the canonical form contains only the names of the files in
which the pictures are found.</P>
<P>
Thus, there are two types of buffers: buffers for reading from the terminal
(filled by the <TT>Read</TT> rule) and the buffer of picture names (containing
the name of the last picture encountered). A translation schema can use
either type, one or several read buffers and one (and only one) picture name
buffer.</P>
<P>
If any buffers are used, the <TT>BUFFERS</TT> keyword must be present,
followed by declarations of every buffer used in the translation schema. Each
buffer declaration is composed only of the name of the buffer, chosen freely
by the programmer. The picture name buffer is identified by the
<TT>Picture</TT> keyword, between parentheses, following the buffer name. The
<TT>Picture</TT> keyword may only appear once. Each buffer declaration is
terminated by a semicolon.</P>
<PRE>
BufferSeq = Buffer < Buffer > .
Buffer = BufferID [ '(' 'Picture' ')' ] ';' .
BufferID = NAME .
</PRE>
<BLOCKQUOTE class="example">
<P>
<STRONG>Example:</STRONG></P>
<P>
The following buffer declarations create a picture name buffer named
<TT>pictureName</TT> and a read buffer named <A
name="destname"><TT>DestName</TT></A>:</P>
<PRE>
BUFFERS
pictureName (Picture); DestName;
</PRE>
</BLOCKQUOTE>
</DIV>
<DIV class="subsection">
<H3><A name="counters">Counters</A></H3>
<P>
Certain translation rules generate text that varies according to the context
of the element to which the rules apply. Variable text is defined either in
the <A href="#varsect"><TT>VAR</TT> section</A> of the translation schema or
in the rule itself (see the <TT>Create</TT> and <TT>Write</TT> rules). Both
types of definition rely on counters for the calculation of variable
material.</P>
<P>
There are two types of counter: counters whose value is explicitely computed
by applying <A href="#setandadd"><TT>Set</TT> and <TT>Add</TT> rules</A>, and
counters whose value is computed by a function associated with the counter.
Those functions allow the same calculations as can be used in presentation
schemas. As in a presentation schema, counters must be defined in the
<TT>COUNTERS</TT> section of the translation schema before they are used.</P>
<P>
When counters are used in a translation schema, the <TT>COUNTERS</TT> keyword
is followed by the declarations of every counter used. Each declaration is
composed of the counter's name possibly followed by a colon and the counting
function to be used for the counter. The declaration is terminated by a
semi-colon. If the counter is explicitely computed by <TT>Set</TT> and
<TT>Add</TT> rules, no counting function is indicated. If a counting function
is indicated, <TT>Set</TT> and <TT>Add</TT> rules cannot be applied to that
counter.</P>
<P>
The counting function indicates how the counter's value will be computed.
Three functions are available: <TT>Rank</TT>, <TT>Rlevel</TT>, and
<TT>Set</TT>.</P>
<UL>
<LI><TT>Rank of ElemID</TT>indicates that the counter's value is the rank of
the element of type <TT>ElemID</TT>which encloses the element for which the
counter is being evaluated. For the purposes of this function, an element of
type <TT>ElemID</TT>is considered to enclose itself. This function is
primarily used when the element of type <TT>ElemID</TT>is part of an
aggregate or list, in which case the counter's value is the element's rank in
its list or aggregate. Note that, unlike the<TT>Rank</TT>function for
presentation schemas, the <TT>Page</TT>keyword cannot be used in place of the
<TT>ElemID</TT>.
<P>
The type name <TT>ElemID</TT> can be followed by an integer. That number
represents the relative level, among the ancestors of the concerned element,
of the element whose rank is asked. If that relative level <I>n</I> is
unsigned, the $n^th$ element of type <TT>ElemID</TT> encountered when
travelling the logical structure from the root to the concerned element is
taken into account. If the relative level is negative, the logical structure
is travelled in the other direction, from the concerned element to the
root.</P>
<LI><TT>Rlevel of ElemID</TT>indicates that the counter's values is the
relative level in the tree of the element for which the counter is being
evaluated. The counter counts the number of elements of type <TT>ElemID</TT>
which are found on the path between the root of the document's logical
structure tree and the element (inclusive).
<LI><TT>Set n on Type1 Add m on Type2</TT>indicates that the counter's value
is calculated as follows: in traversing the document from the beginning to
the element for which the counter is being evaluated, the counter is set to
the value <TT>n</TT>each time a <TT>Type1</TT>element is encountered and is
incremented by the amount <TT>m</TT>each time a<TT>Type2</TT>element is
encountered. The initial value <TT>n</TT>and the increment <TT>m</TT>are
integers.
</UL>
<P>
As in a presentation schema, the <TT>Rank</TT> and <TT>Set</TT> functions can
be modified by a numeric attribute which changes their initial value. This is
indicated by the <TT>Init</TT> keyword followed by the numeric attribute's
name. The <TT>Set</TT> function takes the value of the attribute instead of
the <TT>InitValue</TT> (<TT>n</TT>). For the <TT>Rank</TT> function, the
value of the attribute is considered to be the rank of the first element of
the list (rather than the normal value of 1). Subsequent items in the list
have their ranks shifted accordingly. In both cases, the attribute must be
numeric and must be a local attribute of the root of the document itself.</P>
<PRE>
CounterSeq = Counter < Counter > .
Counter = CounterID [ ':' CounterFunc ] ';' .
CounterID = NAME .
CounterFunc = 'Rank' 'of' ElemID [ SLevelAsc ]
[ 'Init' AttrID ] /
'Rlevel' 'of' ElemID /
'Set' InitValue 'On' ElemID
'Add' Increment 'On' ElemID
[ 'Init' AttrID ] .
SLevelAsc = [ '-' ] LevelAsc .
LevelAsc = NUMBER .
InitValue = NUMBER .
Increment = NUMBER .
ElemID = NAME .
AttrID = NAME .
</PRE>
<BLOCKQUOTE class="example">
<P>
<STRONG>Example:</STRONG></P>
<P>
If the body of a chapter is defined in the structure schema by:</P>
<PRE>
Chapter_Body = LIST OF
(Section = BEGIN
Section_Title = Text;
Section_Body = BEGIN
Paragraphs;
Section;
END;
END
);
</PRE>
<P>
(sections are defined recursively), a counter can be defined giving the <A
name="sectnum">number of a section</A>within its level in the hierarchy:</P>
<PRE>
COUNTERS
SectionNumber : Rank of Section;
</PRE>
<P>
A counter holding the hierarchic level of a section:</P>
<PRE>
SectionLevel : Rlevel of Section;
</PRE>
<P>
A <A name="uniquenum">counter</A>which sequentially numbers all thedocument's
sections, whatever their hierarchic level:</P>
<PRE>
UniqueSectNum : Set 0 on Document Add 1 on Section;
</PRE>
</BLOCKQUOTE>
</DIV>
<DIV class="subsection">
<H3>Constants</H3>
<P>
A common feature of translation rules is the generation of constant text. This
text can be defined in the rule that generates it (see for example the <A
href="#create"><TT>Create</TT></A> and <A href="#writerule"><TT>Write</TT></A>
rules); but it can also be defined once in the constant declaration section
and used many times in different rules. The latter option is preferable when
the same text is used in several rules or several <A
href="#varsect">variables</A>.</P>
<P>
The <TT>CONST</TT> keyword begins the constant declaration section of the
translation schema. It must be omitted if no constants are declared. Each
constant declaration is composed of the constant name, an equals sign, and the
constant's value, which is a character string between apostrophes. A constant
declaration is terminated by a semicolon.</P>
<PRE>
ConstSeq = Const < Const > .
Const = ConstID '=' ConstValue ';' .
ConstID = NAME .
ConstValue = STRING .
</PRE>
<BLOCKQUOTE class="example">
<P>
<STRONG><A name="levelexample">Example:</A></STRONG></P>
<P>
The following rule assigns the name <TT>TxtLevel</TT>to the character string
``Level'':</P>
<PRE>
CONST
TxtLevel = 'Level';
</PRE>
</BLOCKQUOTE>
</DIV>
<DIV class="subsection">
<H3><A name="varsect">Variables</A></H3>
<P>
Variables allow to define file names or variable text which is generated by
the <TT>Create</TT> and <TT>Write</TT> rules. Variables can be defined either
in the <TT>VAR</TT> section of the translation schema or directly in the rules
which use them. Variables that define fine names must be declared in the
<TT>VAR</TT> section, and when the same variable is used several times in the
translation schema, it makes sense to define it globally in the <TT>VAR</TT>
section. This section is only present if at least one variable is defined
globally.</P>
<P>
After the <TT>VAR</TT> keyword, each global variable is defined by its name, a
colon separator and a sequence of functions (at least one function). Each
variable definition is terminated by a semicolon. Functions determine the
different parts which together give the value of the variable. The value is
obtained by concatenating the strings produced by each of the functions. Seven
types of functions are available. Each variable definition may use any number
of functions of each type.</P>
<UL>
<LI>The function <TT>Value(Counter)</TT>returns a string representing the
value taken by the counter when it is evaluated for the element in whose rule
the variable is used. The counter must have been declared in the
<TT>COUNTERS</TT>section of the translation schema. When thecounter is
expressed in arabic numerals, the counter name can be followed by a colon and
an integer indicating a minimum length (number of characters) for the string;
if the counter's value is normally expressed with fewer characters than the
required minimum, zeroes are added to the front of the string to achieve the
minimumlength.
<P>
By default, the counter value is written in arabic digits. If another
representation of that value is needed, the counter name must be followed by a
comma and one of the following keywords:</P>
<UL>
<LI><TT>Arabic</TT>: arabic numerals (default value),
<LI><TT>LRoman</TT>: lower-case roman numerals,
<LI><TT>URoman</TT>: upper-case roman numerals,
<LI><TT>Uppercase</TT>: upper-case letter,
<LI><TT>Lowercase</TT>: lower-case letter.
</UL>
<LI>The function <TT>FileDir</TT>, without parameter, returns a string
representing the name of the directory of the output file that has been given
as a parameter to the translation program. The string includes a character '/'
at the end.
<LI>The function <TT>FileName</TT>, without parameter, returns a string
representing the name of the output file that has been given as a parameter to
the translation program. The file extension (the character string that
terminate the file name, after a dot) is not part of that string.
<LI>The function <TT>Extension</TT>, without parameter, returns a string
representing the extension of the file name. That string is empty if the file
name that has been given as a parameter to the translation program has no
extension. If there is an extension, its first character is a dot.
<LI>The function <TT>DocumentName</TT>, without parameter, returns a string
representing the name of the document being translated.
<LI>The function <TT>DocumentDir</TT>, without parameter, returns a string
representing the directory containing the document being translated.
<LI>The function formed by the name of a constant returns that constant's
value.
<LI>The function formed by a character string between apostrophes returns that
string.
<LI>The function formed by the name of a buffer returns the contents of that
buffer. If the named buffer is the picture buffer, then the name of the last
picture encountered is returned. Otherwise, the buffer is a read buffer and
the value returned is text previously read from the terminal. If the buffer
is empty (no picture has been encountered or the <TT>Read</TT> rule has not
been executed for the buffer), then the empty string is returned.
<LI>The function formed by an attribute name takes the value of the indicated
attribute for the element to which the variable applies. If the element does
not have that attribute, then the element's ancestor are searched toward the
root of the tree. If one of the ancestors does have the attribute then its
value is used. If no ancestors have the attribute, then the value of the
function is the empty string.
</UL>
<PRE>
VariableSeq = Variable < Variable > .
Variable = VarID ':' Function < Function > ';' .
VarID = NAME .
Function ='Value' '(' CounterID [ ':' Length ]
[ ',' CounterStyle ] ')' /
'FileDir' / 'FileName' / 'Extension' /
'DocumentName' / 'DocumentDir' /
ConstID / CharString /
BufferID / AttrID .
Length = NUMBER .
CounterStyle= 'Arabic' / 'LRoman' / 'URoman' /
'Uppercase' / 'Lowercase' .
CharString = STRING .
</PRE>
<BLOCKQUOTE class="example">
<P>
<STRONG>Example:</STRONG></P>
<P>
To create, at the beginning of each section of the translated document, text
composed of the string ``Section'' followed by the section number, the
following <A name="varsectexample">variable definition</A>might be used:</P>
<PRE>
VAR
SectionVar : 'Section' Value(SectionNumber);
</PRE>
<P>
(see the definition of <A href="#sectnum"><TT>SectionNumber</TT></A>).</P>
<P>
The following variable definition can be used to create, at the beginning of
each section, the text ``Level'' followed by the hierarchical level of the
section. It used the constant defined above.</P>
<PRE>
LevelVar : TxtLevel Value(SectionLevel);
</PRE>
<P>
(see the definitions of <A href="#sectnum"><TT>SectionLevel</TT></A>and of <A
href="#levelexample"><TT>TxtLevel</TT></A>).</P>
<P>
To generate the translation of each section in a different file (see <A
href="#changemainfile">rule <TT>ChangeMainFile</TT></A>), the name of these
files might be defined by the following variable:</P>
<PRE>
VarOutpuFile : FileName Value(SectionNumber)
Extension;
</PRE>
<P>
If <TT>output.txt</TT>is the name of the <A name="varoutputfile">output
file</A>specified when starting the translation program, translatedsections
are written in files <TT>output1.txt</TT>, <TT>output2.txt</TT>,etc.</P>
</BLOCKQUOTE>
</DIV>
<DIV class="subsection">
<H3>Translating structure elements</H3>
<P>
The <TT>RULES</TT> keyword introduces the translation rules which will be
applied to the various structured element types. Translation rules can be
specified for each element type defined in the structure schema, including the
base types defined implicitly, whose names are <TT>TEXT_UNIT</TT>,
<TT>PICTURE_UNIT</TT>, <TT>SYMBOL_UNIT</TT>, <TT>GRAPHIC_UNIT</TT> and
<TT>PAGE_UNIT</TT>. But it is not necessary to specify rules for every
defined type.</P>
<P>
If there are no translation rules for an element type, the elements that it
contains (and which may have rules themselves) will still be translated, but
the translator will produce nothing for the element itself. To make the
translator completely ignore the content of an element the <A
href="#remove"><TT>Remove</TT> rule</A> must be used.</P>
<P>
The translation rules for an element type defined in the structure schema are
written using the name of the type followed by a colon and the list of
applicable rules. When the element type is a <A href="#pairs">mark pair</A>,
but only in this case, the type name must be preceded by the <TT>First</TT> or
<TT>Second</TT> keyword. This keyword indicates whether the rules that follow
apply to the first or second mark of the pair.</P>
<P>
The list of rules can take several forms. It may be a simple non-conditional
rule. It can also be formed by a condition followed by one or more simple
rules. Or it can be a block of rules beginning with the <TT>BEGIN</TT>
keyword and ending with the <TT>END</TT> keyword and a semicolon. This block
of rules can contain one or more simple rules and/or one or more conditions,
each followed by one or more simple rules.</P>
<PRE>
ElemSeq = TransType < TransType > .
TransType = [ FirstSec ] ElemID ':' RuleSeq .
FirstSec = 'First' / 'Second' .
RuleSeq = Rule / 'BEGIN' < Rule > 'END' ';' .
Rule = SimpleRule / ConditionBlock .
ConditionBlock = 'IF' ConditionSeq SimpleRuleSeq .
SimpleRuleSeq = 'BEGIN' < SimpleRule > 'END' ';' /
SimpleRule .
</PRE>
</DIV>
<DIV class="subsection">
<H3><A name="transcond">Conditional rules</A></H3>
<P>
In a translation schema, the translation rules are either associated with
element types or with attribute values or with a specific presentation. They
are applied by the translator each time an element of the corresponding type
is encountered in the translated document or each time the attribute value is
carried by an element or also, each time the specific translation is attached
to an element. This systematic application of the rules can be relaxed: it is
possible to add a condition to one or more rules, so that these rules are only
applied when the condition is true.</P>
<P>
A condition begins with the keyword <TT>IF</TT>, followed by a sequence of
elementary conditions. Elementary conditions are separated from each other by
the <TT>AND</TT> keyword. If there is only one elementary condition, this
keyword is absent. The rules are only applied if all the elementary
conditions are true. The elementary condition can be negative; it is then
preceded by the <TT>NOT</TT> keyword.</P>
<P>
When the translation rule(s) controlled by the condition apply to a reference
element or a reference attribute, an elementary condition can also apply to
element referred by this reference. The <TT>Target</TT> keyword is used for
that purpose. It must appear before the keyword defining the condition
type.</P>
<P>
Depending on their type, some conditions may apply either to the element with
which they are associated, or to one of its ancestor. In the case od an
ancestor, the key word <TT>Ancestor</TT> must be used, followed by</P>
<UL>
<LI>either an integer which represents the number of levels in the tree
between the element and the ancestor of interest,
<LI>or the type name of the ancestor of interest. If that type is defined in
a separate structure schema, the name of that schema must follow between
parentheses.
</UL>
<P>
There is a special case for the parent element, which can be simply written
<TT>Parent</TT>instead of <TT>Ancestor 1</TT>.</P>
<P>
Only conditions <TT>First</TT>, <TT>Last</TT>, <TT>Referred</TT>,
<TT>Within</TT>, <TT>Attributes</TT>, <TT>Presentation</TT>, <TT>Comment</TT>
and those concerning an attribute or a specific presentation can apply to an
ancestor. Conditions <TT>Defined</TT>, <TT>FirstRef</TT>, <TT>LastRef</TT>,
<TT>ExternalRef</TT>, <TT>Alphabet</TT>, <TT>FirstAttr</TT>,
<TT>LastAttr</TT>, <TT>ComputedPage</TT>, <TT>StartPage</TT>,
<TT>UserPage</TT>, <TT>ReminderPage</TT>, <TT>Empty</TT> cannot be preceded by
keywords <TT>Parent</TT> or <TT>Ancestor</TT>.</P>
<P>
In condition <TT>Referred</TT> and in the condition that applies to a named
attribute, a symbol <TT>*</TT> can indicate that the condition is related only
to the element itself. If this symbol is not present, not only the element is
considered, but also its ancestor, at any level.</P>
<P>
The form of an elementary condition varies according to the type of
condition.</P>
<DIV class="subsubsection">
<H4>Conditions based on the logical position of the element</H4>
<P>
The condition can be on the position of the element in the document's logical
structure tree. It is possible to test whether the element is the first
(<TT>First</TT>) or last (<TT>Last</TT>) among its siblings or if it is not
the first (<TT>NOT First</TT>) or not the last (<TT>NOT Last</TT>).</P>
<P>
It is also possible to test if the element is contained in an element of a
given type (<TT>Within</TT>) or if it is not (<TT>NOT Within</TT>). If that
element type is defined in a structure schema which is not the one which
corresponds to the translation schema, the type name of this element must be
followed, between parentheses, by the name of the structure schema which
defines it.</P>
<P>
If the keyword <TT>Within</TT> is preceded by <TT>Immediately</TT>, the
condition is satisfied only if the <EM>parent</EM> element has the type
indicated. If the word <TT>Immediately</TT> is missing, the condition is
satisfied if any <EM>ancestor</EM> has the type indicated.</P>
<P>
An integer <I>n</I> can appear between the keyword <TT>Within</TT> and the
type. It specifies the number of ancestors of the indicated type that must be
present for the condition to be satisfied. If the keyword
<TT>Immediately</TT> is also present, the <I>n</I> immediate ancestors of the
element must have the indicated type. The integer <I>n</I> must be positive
or zero. It can be preceded by <TT><</TT> or <TT>></TT> to indicate a
maximum or minimum number of ancestors. If these symbols are missing, the
condition is satisfied only if it exists exactly <I>n</I> ancestors. When
this number is missing, it is equivalent to > 0.</P>
</DIV>
<DIV class="subsubsection">
<H4>Conditions on references</H4>
<P>
References may be taken into account in conditions, which can be based on the
fact that the element, or one of its ancestors (unless symbol <TT>*</TT> is
present), is designated by a at least one reference (<TT>Referred</TT>) or by
none (<TT>NOT Referred</TT>). If the element or attribute to which the
condition is attached is a reference, the condition can be based on the fact
that it acts as the first reference to the designated element
(<TT>FirstRef</TT>), or as the last (<TT>LastRef</TT>), or as a reference to
an element located in another document (<TT>ExternalRef</TT>). Like all
conditions, conditions on references can be inverted by the <TT>NOT</TT>
keyword.</P>
</DIV>
<DIV class="subsubsection">
<H4>Conditions on the parameters</H4>
<P>
Elements which are <A href="#param">parameters</A> can be given a particular
condition which is based on whether or not the parameter is given a value in
the document (<TT>Defined</TT> or <TT>NOT Defined</TT>, respectively).</P>
</DIV>
<DIV class="subsubsection">
<H4>Conditions on the alphabets</H4>
<P>
The character string base type (and only this type) can use the condition
<TT>Alphabet = a</TT> which indicates that the translation rule(s) should only
apply if the alphabet of the character string is the one whose name appears
after the equals sign (or is not, if there is a preceding <TT>NOT</TT>
keyword). This condition cannot be applied to translation rules of an
attribute.</P>
<P>
In the current implementation of Thot, the available alphabets are the
<TT>Latin</TT> alphabet and the <TT>Greek</TT> alphabet.</P>
</DIV>
<DIV class="subsubsection">
<H4>Conditions on page breaks</H4>
<P>
The page break base type (and only this type) can use the following
conditions: <TT>ComputedPage</TT>, <TT>StartPage</TT>, <TT>UserPage</TT>, and
<TT>ReminderPage</TT>. The <TT>ComputedPage</TT> condition indicates that the
translation rule(s) should apply if the page break was created automatically
by Thot; the <TT>StartPage</TT> condition is true if the page break is
generated before the element by the <TT>Page</TT> rule of the P language; the
<TT>UserPage</TT> condition applies if the page break was inserted by the
user; and the <TT>ReminderPage</TT> is applied if the page break is a reminder
of page breaking.</P>
</DIV>
<DIV class="subsubsection">
<H4>Conditions on the element's content</H4>
<P>
The condition can be based on whether or not the element is empty. An element
which has no children or whose leaves are all empty is considered to be empty
itself. This condition is expressed by the <TT>Empty</TT> keyword, optionally
preceded by the <TT>NOT</TT> keyword.</P>
</DIV>
<DIV class="subsubsection">
<H4>Conditions on the presence of comments</H4>
<P>
The condition can be based on the presence or absence of comments associated
with the translated element. This condition is expressed by the keyword
<TT>Comment</TT>, optionally preceded by the keyword <TT>NOT</TT>.</P>
</DIV>
<DIV class="subsubsection">
<H4>Conditions on the presence of specific presentation rules</H4>
<P>
The condition can be based on the presence or absence of specific presentation
rules associated with the translated element, whatever the rules, their value
or their number. This condition is expressed by the keyword
<TT>Presentation</TT>, optionally preceded by the <TT>NOT</TT> keyword.</P>
</DIV>
<DIV class="subsubsection">
<H4>Conditions on the presence of logical attributes</H4>
<P>
In the same way, the condition can be based on the presence or absence of
attributes associated with the translated elements, no matter what the
attributes or their values. The <TT>Attributes</TT> keyword expresses this
condition.</P>
</DIV>
<DIV class="subsubsection">
<H4>Conditions on logical attributes</H4>
<P>
If the condition appears in the translation rules of an attribute, the
<TT>FirstAttr</TT> and <TT>LastAttr</TT> keywords can be used to indicate that
the rules must only be applied if this attribute is the first attribute for
the translated element or if it is the last (respectively). These conditions
can also be inverted by the <TT>NOT</TT> keyword.</P>
<P>
Another type of condition can only be applied to the translation rules when
the element being processed (or one of its ancestors if symbol <TT>*</TT> is
missing) has a certain attribute, perhaps with a certain value or, in
contrast, when the element does not have this attribute with this value. The
condition is specified by writing the name of the attribute after the keyword
<TT>IF</TT> or <TT>AND</TT>. The <TT>NOT</TT> keyword can be used to invert
the condition. If the translation rules must be applied to any element which
has this attribute (or does not have it, if the condition is inverted) no
matter what the attribute's value, the condition is complete. If, in
contrast, the condition applies to one or more values of the attribute, these
are indicated after the name of the attribute, except for reference attributes
which do not have values.</P>
<P>
The representation of the values of an <A name="relattr">attribute</A> in a
condition depends on the attribute's type. For attributes with enumerated or
textual types, the value (a name or character string between apostrophes,
respectively) is simply preceded by an equals sign. For numeric attributes,
the condition can be based on a single value or on a range of values. In the
case of a unique value, this value (an integer) is simply preceded by an
equals sign. Conditions based on ranges of values have several forms:</P>
<UL>
<LI>all values less than a given value (the value is preceded by a ``less
than'' sign).
<LI>all values greater than a given value (the value is preceded by a
``greater than'' sign).
<LI>all values falling in an interval, bounds included. The range of values
is then specified <TT>IN [</TT>Minimum <TT>..</TT>Maximum<TT>]</TT>, where
Minimum and Maximum are integers.
</UL>
<P>
All numeric values may be negative. The integer is simply preceded by a minus
sign.</P>
<P>
Both local and global attributes can be used in conditions.</P>
</DIV>
<DIV class="subsubsection">
<H4>Conditions on specific presentation rules</H4>
<P>
It is possible to apply translation rules only when the element being
processed has or does not have a specific presentation rule, possibly with a
certain value. The condition is specified by writing the name of the
presentation rule after the keyword <TT>IF</TT> or <TT>AND</TT>. The
<TT>NOT</TT> keyword can be used to invert the condition. If the translation
rules must be applied to any element which has this presentation rule (or does
not have it, if the condition is inverted) no matter what the rule's value,
the condition is complete. If, in contrast, the condition applies to one or
more values of the rule, these are indicated after the name of the
attribute.</P>
<P>
The representation of presentation rule values in a condition is similar to
that for attribute values. The representation of these values depend on the
type of the presentation rule. There are three categories of presentation
rules:</P>
<UL>
<LI>those taking numeric values (<TT>Size, Indent, LineSpacing,
LineWeight</TT>),
<LI>those with values taken from a predefined list (<TT>Adjust, Justify,
Hyphenate, Style, Font, UnderLine, Thickness, LineStyle</TT>),
<LI>those whose value is a name (<TT>FillPattern, Background,
Foreground</TT>).
</UL>
<P>
For presentation rules which take numeric values, the condition can take a
unique value or a range of values. In the case of a unique value, this value
(an integer) is simply preceded by an equals sign. Conditions based on ranges
of values have several forms:</P>
<UL>
<LI>all values less than a given value (the value is preceded by a ``less
than'' sign).
<LI>all values greater than a given value (the value is preceded by a
``greater than'' sign).
<LI>all values falling in an interval, bounds included. The range of values
is then specified <TT>IN [</TT>Minimum <TT>..</TT>Maximum<TT>]</TT>, where
Minimum and Maximum are integers.
</UL>
<P>
Values for the <TT>Indent</TT>rule may be negative. The integer is then
simply preceded by a minus sign and represents how far the first line starts
to the left of the other lines.</P>
<P>
For presentation rules whose values are taken from predefined lists, the value
which satisfies the condition is indicated by an equals sign followed by the
name of the value.</P>
<P>
For presentation rule whose values are names, the value which satisfies the
condition is indicated by the equals sign followed by the value's name. The
names of fill patterns (the <TT>FillPattern</TT> rule) and of colors (the
<TT>Foreground</TT> and <TT>Background</TT> rules) known to Thot are the same
as in the P language.</P>
<P>
The syntax of conditions based on the specific presentation is the same as the
syntax used to express the <A href="#prestrans">translation of specific
presentation rules</A>.</P>
<P>
When a condition has only one rule, the condition is simply followed by that
rule. If it has several rules, they are placed after the condition between
the keywords <TT>BEGIN</TT> and <TT>END</TT>.</P>
<PRE>
ConditionSeq = Condition [ 'AND' Condition ] .
Condition = [ 'NOT' ] [ 'Target' ] Cond .
Cond = CondElem / CondAscend .
CondElem ='FirstRef' / 'LastRef' /
'ExternalRef' /
'Defined' /
'Alphabet' '=' Alphabet /
'ComputedPage' / 'StartPage' /
'UserPage' / 'ReminderPage' /
'Empty' /
'FirstAttr' / 'LastAttr' .
CondAscend = [ Ascend ] CondOnAscend .
Ascend = '*' / 'Parent' / 'Ancestor' LevelOrType .
LevelOrType = CondRelLevel / ElemID [ ExtStruct ] .
CondRelLevel = NUMBER .
CondOnAscend ='First' / 'Last' /
'Referred' /
[ 'Immediately' ] 'Within' [ NumParent ]
ElemID [ ExtStruct ] /
'Attributes' /
AttrID [ RelatAttr ] /
'Presentation' /
PresRule /
'Comment' .
NumParent = [ GreaterLess ] NParent .
GreaterLess = '>' / '<' .
NParent = NUMBER.
ExtStruct = '(' ElemID ')' .
Alphabet = NAME .
RelatAttr ='=' Value /
'>' [ '-' ] Minimum /
'<' [ '-' ] Maximum /
'IN' '[' [ '-' ] MinInterval '..'
[ '-' ] MaxInterval ']' .
Value = [ '-' ] IntegerVal / TextVal / AttrValue .
Minimum = NUMBER .
Maximum = NUMBER .
MinInterval = NUMBER .
MaxInterval = NUMBER .
IntegerVal = NUMBER .
TextVal = STRING .
AttrValue = NAME .
</PRE>
<BLOCKQUOTE class="example">
<P>
<STRONG>Example:</STRONG></P>
<P>
Suppose that after each element of type Section_Title it is useful to produce
the text <TT>\label{SectX}</TT> where <TT>X</TT> represents the section number,
but only if the section is designated by one or more references in the
document. The following conditional rule produces this effect:</P>
<PRE>
RULES
Section_Title :
IF Referred
Create ('\label{Sect' Value(UniqueSectNum)
'}\12') After;
</PRE>
<P>
(the declaration of the <A href="#prestrans"><TT>UniqueSectNum</TT>
counter</A> is given above). The string <TT>\12</TT> represents a line
break.</P>
</BLOCKQUOTE>
<BLOCKQUOTE class="example">
<P>
<STRONG>Example:</STRONG></P>
<P>
Suppose that for elements of the Elmnt type it would be useful to produce a
character indicating the value of the numeric attribute Level associated with
the element: an ``A'' for all values of Level less than 3, a ``B'' for values
between 3 and 10 and a ``C'' for values greater than 10. This can be achieved
by writing the following rules for the Elmnt type:</P>
<PRE>
RULES
Elmnt :
BEGIN
IF Level < 3
Create 'A';
IF Level IN [3..10]
Create 'B';
IF Level > 10
Create 'C';
END;
</PRE>
</BLOCKQUOTE>
</DIV>
</DIV>
<DIV class="subsection">
<H3>Translation rules</H3>
<P>
Thirteen types of translation rules can be associated with element types and
attribute values. They are the <TT>Create</TT>, <TT>Write</TT>,
<TT>Read</TT>, <TT>Include</TT>, <TT>Get</TT>, <TT>Copy</TT>, <TT>Use</TT>,
<TT>Remove</TT>, <TT>NoTranslation</TT>, <TT>NoLineBreak</TT>,
<TT>ChangeMainFile</TT>, <TT>Set</TT>, <TT>Add</TT> rules. Each rule has its
own syntax, although they are all based on very similar models.</P>
<PRE>
SimpleRule = 'Create' [ 'IN' VarID ] Object
[ Position ] ';' /
'Write' Object [ Position ] ';' /
'Read' BufferID [ Position ] ';' /
'Include' File [ Position ] ';' /
'Get' [ RelPosition ] ElemID
[ ExtStruct ]
[ Position ] ';' /
'Copy' [ RelPosition ] ElemID
[ ExtStruct ]
[ Position ] ';' /
'Use' TrSchema [ 'For' ElemID ] ';' /
'Remove' ';' /
'NoTranslation' ';' /
'NoLineBreak' ';' /
'ChangeMainFile' VarID [ Position ] ';' /
'Set' CounterID InitValue
[ Position ] ';' /
'Add' CounterID Increment
[ Position ] ';' .
</PRE>
</DIV>
<DIV class="subsection">
<H3><A name="create">The <TT>Create</TT> rule</A></H3>
<P>
The most frequently used rule is undoubtedly the <TT>Create</TT> rule, which
generates fixed or variable text (called an <EM>object</EM>) in the output
file. The generated text can be made to appear either before or after the
content of the element to which the rule applies. The rule begins with the
<TT>Create</TT> keyword, followed by a specifier for the object and a keyword
(<TT>Before</TT> or <TT>After</TT>) indicating the position of the generated
text (<A href="#order">before or after</A> the element's content). If the
position is not indicated, the object will be generated before the element's
content. This rule, like all translation rules, is terminated by a
semicolon.</P>
<P>
The <TT>Create</TT> keyword can be followed by the <TT>IN</TT> keyword and by
the name of a variable. This means that the text generated by the rule must
not be written in the main output file, but in the file whose name is
specified by the variable.</P>
<P>
This allows the translation program to generate text in different files during
the same run. These files do not need to be explicetely declared or opened.
They do not need to be closed either. As soon as the translation program
executes a <TT>Create</TT> rule for a file that is not yet open, it opens the
file. These files are closed when the translation is finished.</P>
<PRE>
'Create' [ 'IN' VarID ] Object
[ Position ] ';'
Object = ConstID / CharString /
BufferID /
VarID /
'(' Function < Function > ')' /
AttrID /
'Value' /
'Content' /
'Comment' /
'Attributes' /
'Presentation' /
'RefId' /
'PairId' /
'FileDir' /
'FileName' /
'Extension' /
'DocumentName' /
'DocumentDir' /
[ 'Referred' ] ReferredObject .
Position ='After' / 'Before' .
ReferredObject = VarID /
ElemID [ ExtStruct ] /
'RefId' /
'DocumentName' /
'DocumentDir' .
</PRE>
<P>
The object to be generated can be:</P>
<UL>
<LI>a constant string, specified by its name if it is declared in the schema's
<TT>CONST</TT>section, or given directly as a value between apostrophes;
<LI>the contents of a buffer, designated by the name of the buffer;
<LI>a variable, designated by its name if it is declared in the translation
schema's <TT>VAR</TT>section, or given directly between parentheses. The text
generated is the value of that variable evaluated for the element to which the
rule applies.
<LI>the value of an attribute, if the element being translated has this
attribute. The attribute is specified by its name;
<LI>the value of a specific presentation rule. This object can only be
generated if the translation rule is for a <A href="#prestransl">specific
presentation rule</A>. It is specified by the <TT>Value</TT> keyword;
<LI>the element's content. That is, the content of the leaves of the subtree
of the translated element. This is specified by the <TT>Content</TT> keyword;
<LI>the comment attached to the element. When the element doesn't have a
comment, nothing is generated. This is indicated by the <TT>Comment</TT>
keyword;
<LI>the translation of all attributes of the element (which is primarily used
to apply the attribute translation rules <A href="#order">before</A> those of
the element type). This is specified by the <TT>Attributes</TT> keyword.
<LI>the translation of all of the element's specific presentation rules (which
is primarily used to apply the translation rules for the specific presentation
rules <A href="#order">before</A> those of the element or its attributes).
This option is specified by the <TT>Presentation</TT> keyword;
<LI>The value of the reference's identifier.<BR>Thot associatesa unique
identifier with each element in a document. This identifier (called
<EM>reference's identifier</EM> or <EM>label</EM>) is a character string
containing the letter `L' followed by digits. Thot uses it in references for
identifying the referred element.<BR>The <TT>RefId</TT> keyword produces the
reference's identifier of the element to which the translation rule is
applied, or the reference's identifier of its first ancestor that is referred
by a reference or that can be referred by a reference.
<LI>the value of a mark pair's unique identifier. This may only be used for
<A href="#pairs">mark pairs</A> and is indicated by the <TT>PairId</TT>
keyword.
<LI>the directory containing the file being generated (this string includes an
ending '/', if it is not empty). This is indicated by the <TT>FileDir</TT>
keyword.
<LI>the name of the file being generated (only the name, without the directory
and without the extension). This is indicated by the <TT>FileName</TT>
keyword.
<LI>the extension of the file being generated (this string starts with a dot,
if it is not empty). This is indicated by the <TT>Extension</TT> keyword.
<LI>the name of the document being translated. This is indicated by the
<TT>DocumentName</TT> keyword.
<LI>the directory containing the document being translated. This is indicated
by the <TT>DocumentDir</TT> keyword.
</UL>
<P>
When the rule applies to a reference (an element or an attribute defined as a
reference in the structure schema), it can generate a text related to the
element referred by that reference. The rule name is then followed the
<TT>Referred</TT> keyword and a specification of the object to be generated
for the referred element. This specification can be:</P>
<UL>
<LI>the name of a variable. The rule generates the value of that variable,
computed for the referred element.
<LI>an element type. The rule generates the translation of the element of
that type, which is in the subtree of the referred element. If this element
is not defined in the structure schema which corresponds to the translation
schema (that is, an object defined in another schema), the element's type name
must be followed by the name of its structure schema between parentheses.
<LI>the <TT>RefId</TT> keyword. The rule generates the reference's identifier
of the referred element.
<LI>the <TT>DocumentName</TT> keyword. The rule generates the name of the
document to which the referred element belongs.
<LI>the <TT>DocumentDir</TT> keyword. The rule generates the name of the
directory that contains the document of the referred element.
</UL>
</DIV>
<DIV class="subsection">
<H3><A name="writerule">The <TT>Write</TT> rule</A></H3>
<P>
The <TT>Write</TT> has the same syntax as the <TT>Create</TT> rule. It also
produces the same effect, but the generated text is displayed on the user's
terminal during the translation of the document, instead of being produced in
the translated document. This is useful for helping the user keep track of
the progress of the translation and for prompting the user on the terminal for
input required by the <TT>Read</TT> rule.</P>
<PRE>
'Write' Object [ Position ] ';'
</PRE>
<P>
Notice: if the translator is launched by the editor (by the ``Save as''
command), messages produced by the <TT>Write</TT> rule are not displayed.</P>
<BLOCKQUOTE class="example">
<P>
<STRONG>Example:</STRONG></P>
<P>
To make the translator display the number of each section being translated on
the user's terminal, the following rule is specified for the
<TT>Section</TT> element type:</P>
<PRE>
Section : BEGIN
Write VarSection;
...
END;
</PRE>
<P>
(see <A href="#varsectexample">above</A> for the definition of
the <TT>VarSection</TT> variable).</P>
<P>
To display text on the terminal before issuing a read operation with the
<TT>Read</TT> rule, the following rule is used:</P>
<PRE>
BEGIN
Write 'Enter the name of the destination: ';
...
END;
</PRE>
</BLOCKQUOTE>
</DIV>
<DIV class="subsection">
<H3><A name="readrule">The <TT>Read</TT> rule</A></H3>
<P>
The <TT>Read</TT> rule reads text from the terminal during the translation of
the document and saves the text read in one of the buffers declared in the
<TT>BUFFERS</TT> section of the schema. The buffer to be used is indicated by
its name, after the <TT>READ</TT> keyword. This name can be followed, as in
the <TT>Create</TT> and <TT>Write</TT> rules, by a keyword indicating if the
read operation must be performed <TT>Before</TT> or <TT>After</TT> the
translation of the element's content. If this keyword is absent, the read
operation is done beforehand. The text is read into the buffer and remains
there until a rule using the same buffer --- possibly the same rule --- is
applied.</P>
<PRE>
'Read' BufferID [ Position ] ';'
</PRE>
<BLOCKQUOTE class="example">
<P>
<STRONG>Example:</STRONG></P>
<P>
The following set of rules tells the user that the translator is waiting for
the entry of some text, reads this text into a buffer and copies the text into
the translated document.</P>
<PRE>
BEGIN
Write 'Enter the name of the destination: ';
Read DestName;
Create DestName;
...
END;
</PRE>
<P>
(see <A href="#destname">above</A>the definition of <TT>DestName</TT>).</P>
</BLOCKQUOTE>
</DIV>
<DIV class="subsection">
<H3>The <TT>Include</TT> rule</H3>
<P>
The <TT>Include</TT> rule, like the <TT>Create</TT> rule, is used to produce
text in the translated document. It inserts constant text which is not
defined in the translation schema, but is instead taken from a file. The
file's name is specified after the <TT>Include</TT> keyword, either directly
as a character string between apostrophes or as the name of one of the buffers
declared in the <TT>BUFFERS</TT> section of the schema. In the latter case,
the buffer is assumed to contain the file's name. This can be used when the
included file's name is known only at the moment of translation. This only
requires that the <TT>Include</TT> rule is preceded by a <TT>Read</TT> rule
which puts the name of the file desired by the user into the buffer.</P>
<P>
Like the other rules, it is possible to specify whether the inclusion will
occur before or after the element's content, with the default being before.
The file inclusion is only done at the moment of translation, not during the
compilation of the translation schema. Thus, the file to be included need not
exist during the compilation, but it must be accessible at the time of
translation. Its contents can also be modified between two translations, thus
producing different results, even if neither the document or the translation
schema are modified.</P>
<P>
During translation, the file to be included is searched for along the schema
directory path (indicated by the environment variable <TT>THOTSCH</TT>). The
file name is normally only composed of a simple name, without specification of
a complete file path.</P>
<PRE>
'Include' File [ Position ] ';'
File = FileName / BufferID .
FileName = STRING .
</PRE>
<BLOCKQUOTE class="example">
<P>
<STRONG>Example:</STRONG></P>
<P>
Suppose that it is desirable to print documents of the Article class with a
formatter which requires a number of declarations and definitions at the
beginning of the file. The <TT>Include</TT>rule can be used to achieve this.
All the declarations and definitions a replaced in a file called
<TT>DeclarArt</TT> and then the <TT>Article</TT> element type is given the
following rule:</P>
<PRE>
Article : BEGIN
Include 'DeclarArt' Before;
...
END;
</PRE>
</BLOCKQUOTE>
</DIV>
<DIV class="subsection">
<H3>The <TT>Get</TT> rule</H3>
<P>
The <TT>Get</TT> rule is used to change the order in which the elements appear
in the translated document. More precisely, it produces the translation of a
specified element before or after the translation of the content of the
element to which the rule applies. The <TT>Before</TT> and <TT>After</TT>
keywords are placed at the end of the rule to specify whether the operation
should be performed before or after translation of the rule's element (the
default is before). The type of the element to be moved must be specified
after the <TT>Get</TT> keyword, optionally preceded by a keyword indicating
where the element will be found in the logical structure of the document:</P>
<DL>
<DT><TT>Included</TT></DT>
<DD>The element to be moved is the first element of the indicated type which is
found inside the element to which the rule applies.
</DD>
<DT><TT>Referred</TT></DT>
<DD>This keyword can only be used if the rule applies to a reference element.
The element to be moved is either the element designated by the reference (if
that element is of the specified type), or the first element of the desired
type contained within the element designated by the reference.
</DD>
<DT>no keyword</DT>
<DD>If the element to be moved is an associated element, defined in the <A
href="#assocelem"><TT>ASSOC</TT> section</A> of the structure schema, all
associated elements of this type which have not been translated yet are then
translated. Certain elements may in fact have already been translated by a
<TT>Get Referred</TT> rule.
<P>
If the element to be moved is not an associated element, the translator takes
the first element of the indicated type from among the siblings of the rule's
element. This is primarily used to change the order of the components of an
aggregate.</P>
</DD>
</DL>
<P>
If the element to be moved is defined in a structure schema which is not the
one which corresponds to the translation schema (in the case of an included
object with a different schema), the type name of this element must be
followed, between parentheses, by the name of the structure schema which
defines it.</P>
<PRE>
'Get' [ RelPosition ] ElemID
[ ExtStruct ]
[ Position ] ';' /
RelPosition ='Included' / 'Referred' .
ExtStruct = '(' ElemID ')' .
</PRE>
<P>
The <TT>Get</TT> rule has no effect if the element which it is supposed to
move has already been translated. Thus, the element will not be duplicated.
It is generally best to associate the rule with the first element which will
be encountered by the translator in its traversal of the document. Suppose an
aggregate has two elements <TT>A</TT> and <TT>B</TT>, with <TT>A</TT>
appearing first in the logical structure. To permute these two elements, a
<TT>Get B before</TT> rule should be associated with the <TT>A</TT> element
type, not the inverse. Similarly, a rule of the form <TT>Get Included X
After</TT>, even though syntactically correct, makes no sense since, by the
time it will be applied, after the translation of the contents of the element
to which it is attached, the <TT>X</TT> element will already have been
translated.</P>
<P>
The <TT>Get</TT> rule is the only way to obtain the translation of the
associated elements. In fact, the translator only traverses the primary tree
of the document and thus does not translate the associated elements, except
when the translation is explicitly required by a <TT>Get Referred Type</TT> or
<TT>Get Type</TT> rule where <TT>Type</TT> is an associated element type.</P>
<BLOCKQUOTE class="example">
<P>
<STRONG>Example:</STRONG></P>
<P>
The structure schema defined figures as associated element which are composed
of some content and a caption. Moreover, it is possible to make references to
figures, using elements of the <TT>RefFigure</TT> type:</P>
<PRE>
...
RefFigure = REFERENCE(Figure);
ASSOC
Figure = BEGIN
Content = NATURE;
Caption = Text;
END;
...
</PRE>
<P>
Suppose it would be useful to make a figure appear in the translated document
at the place in the text where the first reference to the figure is made. If
some figures are not referenced, then they would appear at the end of the
document. Also, each figure's caption should appear before the content. The
following rules in the translation schema will produce this result:</P>
<PRE>
Article : BEGIN
...
Get Figures After;
END;
RefFigure : BEGIN
If FirstRef Get Referred Figure;
...
END;
Content : BEGIN
Get Caption Before;
...
END;
</PRE>
</BLOCKQUOTE>
</DIV>
<DIV class="subsection">
<H3>The <TT>Copy</TT> rule</H3>
<P>
Like the <TT>Get</TT> rule, the <TT>Copy</TT> rule generates the translation
of a specified element, but it acts even if the element has already been
translated and it allows to copy it or to translate it later. Both rules have
the same syntax.</P>
<PRE>
'Copy' [ RelPosition ] ElemID
[ ExtStruct ] [ Position ] ';'
</PRE>
</DIV>
<DIV class="subsection">
<H3>The <TT>Use</TT> rule</H3>
<P>
The <TT>Use</TT> rule specifies the translation schema to be applied to
objects of a certain class that are part of the document. This rule only
appears in the rules for the root element of the document (the first type
defined after the <TT>STRUCT</TT> keyword in the structure schema) or the
rules of an element defined by an external structure (by another structure
schema). Also, the <TT>Use</TT> rule cannot be conditional.</P>
<P>
If the rule is applied to an element defined by an external structure, the
<TT>Use</TT> keyword is simply followed by the name of the translation schema
to be used for element constructed according to that external structure. If
the rule is applied to the document's root element, it is formed by the
<TT>Use</TT> keyword followed by the translation schema's name, the
<TT>For</TT> keyword and the name of the external structure to which the
indicated translation schema should be applied.</P>
<PRE>
'Use' TrSchema [ 'For' ElemID ] ';'
TrSchema = NAME .
</PRE>
<P>
If no <TT>Use</TT> rule defines the translation schema to be used for an
external structure which appears in a document, the translator asks the user,
during the translation process, which schema should be used. Thus, it is not
necessary to give the translation schema a <TT>Use</TT> rule for every
external structure used, especially when the choice of translation schemas is
to be left to the user.</P>
<P>
Notice: if the translator is launched by the editor (by the ``Save as''
command), prompts are not displayed.</P>
<BLOCKQUOTE class="example">
<P>
<STRONG>Example:</STRONG></P>
<P>
The <TT>Article</TT>structure schema uses the
<TT>Formula </TT>external structure, defined by another structure schema, for
mathematical formulas:</P>
<PRE>
STRUCTURE Article;
...
STRUCT
Article = ...
...
Formula_in_text = Formula;
Isolated_formula = Formula;
...
END
</PRE>
<P>
Suppose that it would be useful to use the <TT>FormulaT</TT> translation schema
for the formulas of an article. This can be expressed in two different ways in
the <TT>Article</TT>class translation schema, using the rules:</P>
<PRE>
RULES
Article :
Use FormulaT for Formula;
</PRE>
<P>
or:</P>
<PRE>
RULES
...
Formula :
Use FormulaT;
</PRE>
</BLOCKQUOTE>
</DIV>
<DIV class="subsection">
<H3><A name="remove">The <TT>Remove</TT> rule</A></H3>
<P>
The <TT>Remove</TT> rule indicates that nothing should be generated, in the
translated document, for the content of the element to which the rule applies.
The content of that element is simply ignored by the translator. This does
not prevent the generation of text for the element itself, using the
<TT>Create</TT> or <TT>Include</TT> rules, for example.</P>
<P>
The <TT>Remove</TT> rule is simply written with the <TT>Remove</TT> keyword.
It is terminated, like all rules, by a semicolon.</P>
<PRE>
'Remove' ';'
</PRE>
</DIV>
<DIV class="subsection">
<H3><A name="notrans">The <TT>NoTranslation</TT> rule</A></H3>
<P>
The <TT>NoTranslation</TT> rule indicates to the translator that it must not
translate the content of the leaves of the element to which it applies. In
contrast to the <TT>Remove</TT> rule, it does not suppress the content of the
element, but it inhibits the translation of character strings, symbols, and
graphical elements contained in the element. These are retrieved so that
after the translation of the document, the rules of the <A
href="#texttrans"><TT>TEXTTRANSLATE</TT>, <TT>SYMBTRANSLATE</TT> and
<TT>GRAPHTRANSLATE</TT> sections</A> will not be applied to them.</P>
<P>
The <TT>NoTranslation</TT> rule is written with the <TT>NoTranslation</TT>
keyword followed by a semicolon.</P>
<PRE>
'NoTranslation' ';'
</PRE>
</DIV>
<DIV class="subsection">
<H3><A name="nolinebreak">The <TT>NoLineBreak</TT> rule</A></H3>
<P>
The <TT>NoLineBreak</TT> rule indicates to the translator that it must not
generate additional line breaks in the output produced for the element to
which it applies. This is as if it was an <A href="#linelength">instruction
<TT>LINELENGTH 0;</TT></A> at the beginning of the translation schema, but
only for the current element.</P>
<P>
The <TT>NoLineBreak</TT> rule is written with the <TT>NoLineBreak</TT> keyword
followed by a semicolon.</P>
<PRE>
'NoLineBreak' ';'
</PRE>
</DIV>
<DIV class="subsection">
<H3><A name="changemainfile">The <TT>ChangeMainFile</TT> rule</A></H3>
<P>
When the translation program starts, it opens a main output file, whose name
is given as a parameter of the program. All <A href="#create"><TT>Create</TT>
rules</A> without explicit indication of the output file write sequentially in
this file. When a <TT>ChangeMainFile</TT> rule is executed, the main output
file is closed and it is replaced by a new one, whose name is specified in the
<TT>ChangeMainFile</TT> rule. The <TT>Create</TT> rules without indication of
the output file that are then executed write in this new file. Several
<TT>ChangeMainFile</TT> rules can be executed during the same translation, for
dividing the main output into several files.</P>
<P>
This rule is written with the <TT>ChangeMainFile</TT> keyword followed by the
name of a variable that specify the name of the new main file. The keyword
<TT>Before</TT> or <TT>After</TT> can be placed at the end of the rule to
specify whether the operation should be performed before or after translation
of the rule's element (the default is before). This rule, like all translation
rules, is terminated by a semicolon.</P>
<PRE>
'ChangeMainFile' VarID [ Position ] ';'
</PRE>
<BLOCKQUOTE class="example">
<P>
<STRONG>Example:</STRONG></P>
<P>
To generate the translation of each section in a different file, the following
rule can be associated with type <TT>Section</TT>. That rule uses the <A
href="#varoutputfile"><TT>VarOutpuFile</TT> variable</A> defined above.</P>
<PRE>
Section:
ChangeMainFile VarOutpuFile Before;
</PRE>
<P>
If <TT>output.txt</TT> is the name of the output file specified when starting
the translation program, translated sections are written in files
<TT>output1.txt</TT>, <TT>output2.txt</TT>, etc.</P>
</BLOCKQUOTE>
</DIV>
<DIV class="subsection">
<H3><A name="setandadd">The <TT>Set</TT> and <TT>Add</TT> rules</A></H3>
<P>
The <TT>Set</TT> and <TT>Add</TT> rules are used for modifying the value of
counters that have no <A href="#counters">counting function</A>. Only this
type of counter can be used in the <TT>Set</TT> and <TT>Add</TT> rules.</P>
<P>
Both rules have the same syntax: after the keyword <TT>Set</TT> or
<TT>Add</TT> appear the counter name and the value to assign to the counter
(<TT>Set</TT> rule) or the value to be added to the counter (<TT>Add</TT>
rule). The keyword <TT>Before</TT> or <TT>After</TT> can follo9w that value to
indicate when the rule must be applied: before or after the element's content
is translated. By default, <TT>Before</TT> is assumed. A semicolon terminates
the rule.</P>
<PRE>
'Set' CounterID InitValue [ Position ] ';' /
'Add' CounterID Increment [ Position ] ';'
</PRE>
</DIV>
<DIV class="subsection">
<H3><A name="order">Rule application order</A></H3>
<P>
The translator translates the elements which comprise the document in the
order induced by the tree structure, except when the <TT>Get</TT> rule is used
to change the order of translation. For each element, the translator first
applies the rules specified for the element's type that must be applied before
translation of the element's content (rules ending with the <TT>Before</TT>
keyword or which have no position keyword). If several rules meet these
criteria, the translator applies them in the order in where they appear in the
translation schema.</P>
<P>
It then applies all <A href="#transattr">rules for the attributes</A> which
the element has and which must be applied before the translation of the
element's content (rules ending with the <TT>Before</TT> keyword or which have
no position keyword). For one attribute value, the translator applies the
rules in the order in which they are defined in the translation schema.</P>
<P>
The same procedure is followed with translation rules for specific
presentations.</P>
<P>
Next, the element's content is translated, as long as a <TT>Remove</TT> rule
does not apply.</P>
<P>
In the next step, the translator applies rules for the specific presentation
of the element that are to be applied after translation of the content (rules
which end with the <TT>After</TT> keyword). The rules for each type of
presentation rule or each value are applied in the order in which the
translation appear in the schema.</P>
<P>
Then, the same procedure is followed for translation rules for attributes of
the element.</P>
<P>
Finally, the translator applies rules for the element which must be applied
after translation of the element's content. These rules are applied in the
order that they appear in the translation schema. When the translation of an
element is done, the translator procedes to translate the following
element.</P>
<P>
This order can be changed with the <TT>Attributes</TT> and
<TT>Presentation</TT> options of the <A href="#create"><TT>Create</TT>
rule</A>.</P>
</DIV>
<DIV class="subsection">
<H3><A name="transattr">Translation of logical attributes</A></H3>
<P>
After the rules for the element types, the translation schema defines rules
for attribute values. This section begins with the <TT>ATTRIBUTES</TT>
keyword and is composed of a sequence of rule blocks each preceded by an
attribute name and an optional value or value range.</P>
<P>
If the attribute's name appears alone before the rule block, the rule are
applied to all element which have the attribute, no matter what value the
attribute has. In this case, the attribute name is followed by a colon before
the beginning of the rule block.</P>
<P>
The attribute's name can be followed by the name of an element type between
parentheses. This says, as in presentation schemas, that the rule block which
follows applies not to the element which has the attribute, but to its
descendants of the type indicated between the parentheses.</P>
<P>
If values are given after the attribute name (or after the name of the element
type), the rules are applied only when the attribute has the indicated values.
The same attribute can appear several times, with different values and
different translation rules. Attribute values are indicated in the same way
as in <A href="#transcond">conditions</A> and are followed by a colon before
the block of rules.</P>
<P>
The rule block associated with an attribute is either a simple rule or a
sequence of rules delimited by the <TT>BEGIN</TT> and <TT>END</TT> keywords.
Note that rules associated with attribute values cannot be conditional.</P>
<P>
Translation rules are not required for all attributes (or their values)
defined in a structure schema. Only those attributes for which a particular
action must be performed by the translator must have such rules. The rules
that can be used are those described above, from <A
href="#create"><TT>Create</TT></A> to <A
href="#notrans"><TT>NoTranslation</TT></A>.</P>
<PRE>
AttrSeq = TransAttr < TransAttr > .
TransAttr = AttrID [ '(' ElemID ')' ]
[ RelatAttr ] ':' RuleSeq .
AttrID = NAME .
ElemID = NAME .
</PRE>
<BLOCKQUOTE class="example">
<P>
<STRONG>Example:</STRONG></P>
<P>
The structure defined the ``Language'' attribute which can take the values
``French'' and ``English''. To have the French parts of the original document
removed and prevent the translation of the leaves of the English parts, the
following rules would be used:</P>
<PRE>
ATTRIBUTES
Language=French :
Remove;
Language=English :
NoTranslation;
</PRE>
</BLOCKQUOTE>
</DIV>
<DIV class="subsection">
<H3><A name="prestrans">Translation of specific presentations</A></H3>
<P>
After the rules for attributes, the translation schema defines rules for the
specific presentation. This section begins with the <TT>PRESENTATION</TT>
keyword and is composed of a sequence of translation rule blocks each preceded
by a presentation rule name, optionally accompanied by a part which depends on
the particular presentation rule.</P>
<P>
Each of these translation rule blocks is applied when the translator operates
on an element which has a specific presentation rule of the type indicated at
the head of the block. Depending on the type of the specific presentation
rule, it is possible to specify values of the presentation rule for which the
translation rule block should be applied.</P>
<P>
There are three categories of the presentation rules:</P>
<UL>
<LI>rules taking numeric values: <TT>Size</TT>, <TT>Indent</TT>,
<TT>LineSpacing</TT>, <TT>LineWeight</TT>,
<LI>rules whose values are taken from a predefined list (i.e. whose type is an
enumeration): <TT>Adjust</TT>, <TT>Justify</TT>, <TT>Hyphenate,/TT>,
<TT>Style</TT>, <TT>Font</TT>, <TT>UnderLine</TT>, <TT>Thickness</TT>,
<TT>LineStyle</TT>,</TT>
<LI>rules whose value is a name: <TT>FillPattern</TT>, <TT>Background</TT>,
<TT>Foreground</TT>.
</UL>
<P>
For presentation rules of the first category, the values which provoke
application of the translation rules are indicated in the same manner as for
<A href="#relattr">numeric attributes</A>. This can be either a unique value
or range of values. For a unique value, the value (an integer) is simply
preceded by an equals sign. Value ranges can be specified in one of three
ways:</P>
<UL>
<LI>all values less than a given value (this value is preceded by a ``less
than'' sign (<TT><</TT>),
<LI>all values greater than a given value (this value is preceded by a`
`greater than'' sign (<TT>></TT>),
<LI>all values falling in an interval, bounds included. The range of values
is then specified <TT>IN [</TT>Minimum<TT>..</TT>Maximum<TT>]</TT>, where
Minimum and Maximum are integers.
</UL>
<P>
All numeric values can be negative, in which case the integer is preceded by a
minus sign. All values must be given in typographers points.</P>
<P>
For presentation rules whose values are taken from a predefined list, the
value which provokes application of the translation rules is simply indicated
by the equals sign followed by the name of the value.</P>
<P>
For presentation rules whose values are names, the value which provokes the
application of translation rules is simply indicated by the equals sign
followed by the name of the value. The names of the fill patterns (the
<TT>FillPattern</TT> rule) and of the colors (the <TT>Foreground</TT> and
<TT>Background</TT> rules) used in Thot are the same as in the P language.</P>
<PRE>
PresSeq = PresTrans < PresTrans > .
PresTrans = PresRule ':' RuleSeq .
PresRule = 'Size' [ PresRelation ] /
'Indent' [ PresRelation ] /
'LineSpacing' [ PresRelation ] /
'Adjust' [ '=' AdjustVal ] /
'Justify' [ '=' BoolVal ] /
'Hyphenate' [ '=' BoolVal ] /
'Style' [ '=' StyleVal ] /
'Font' [ '=' FontVal ] /
'UnderLine' [ '=' UnderLineVal ] /
'Thickness' [ '=' ThicknessVal ] /
'LineStyle' [ '=' LineStyleVal ] /
'LineWeight' [ PresRelation ] /
'FillPattern' [ '=' Pattern ] /
'Background' [ '=' Color ] /
'Foreground' [ '=' Color ] .
PresRelation = '=' PresValue /
'>' [ '-' ] PresMinimum /
'<' [ '-' ] PresMaximum /
'IN' '[' [ '-' ] PresIntervalMin '..'
[ '-' ] PresIntervalMax ']' .
AdjustVal = 'Left' / 'Right' / 'VMiddle' /
'LeftWithDots' .
BoolVal = 'Yes' / 'No' .
StyleVal = 'Bold' / 'Italics' / 'Roman' /
'BoldItalics' / 'Oblique' /
'BoldOblique' .
FontVal = 'Times' / 'Helvetica' / 'Courier' .
UnderLineVal = 'NoUnderline' / 'UnderLined' /
'OverLined' / 'CrossedOut' .
ThicknessVal = 'Thick' / 'Thin' .
LineStyleVal = 'Solid' / 'Dashed' / 'Dotted' .
Pattern = NAME .
Color = NAME .
PresMinimum = NUMBER .
PresMaximum = NUMBER .
PresIntervalMin= NUMBER .
PresIntervalMax= NUMBER .
PresValue = [ '-' ] PresVal .
PresVal = NUMBER .
</PRE>
<P>
The <A name="prestransl">translation rules associated with specific
presentation rules</A> can use the value of the specific presentation rule
that causes them to be applied. This behavior is designated by the keyword
<TT>Value</TT>. For numerically-valued presentation rules, the numeric value
is produced. For other presentation rules, the name of the value is
produced.</P>
<P>
It should be noted that modifications to the layout of the document's elements
that are made using the combination of the control key and a mouse button will
have no effect on the translation of the document.</P>
<BLOCKQUOTE class="example">
<P>
<STRONG>Example:</STRONG></P>
<P>
Suppose that it is desirable to use the same font sizes as in the specific
presentation, but the font size must be between 10 and 18 typographer's points.
If font size is set in the translated document by the string
<TT>pointsize=n</TT> where <TT>n</TT> is the font size in typographer's points
then the following rules will suffice:</P>
<PRE>
PRESENTATION
Size < 10 :
Create 'pointsize=10';
Size in [10..18] :
BEGIN
Create 'pointsize=';
Create Value;
END;
Size > 18 :
Create 'pointsize=18';
</PRE>
</BLOCKQUOTE>
</DIV>
<DIV class="subsection">
<H3><A name="texttrans">Recoding of characters, symbols and graphics</A></H3>
<P>
The coding of characters, graphical elements and symbols as defined in Thot
does not necessarily correspond to what is required by an application to which
a Thot document must be exported. Because of this the translator can recode
these terminal elements of the documents structure. The last sections of a
translation schema are intended for this purpose, each specifying the recoding
rules for one type of terminal element.</P>
<P>
The recoding rules for character strings are grouped by alphabets. There is a
group of rules for each alphabet of the Thot document that must be translated.
Each such group of rules begins with the <TT>TEXTTRANSLATE</TT> keyword,
followed by the specification of the alphabet to translate and the recoding
rules, between the <TT>BEGIN</TT> and <TT>END</TT> keywords unless there is
only one recoding rule for the alphabet. The specification of the alphabet is
not required: by default it is assumed to the Latin alphabet (the ISO Latin-1
character set).</P>
<P>
Each recoding rule is formed by a source string between apostrophes and a
target string, also between apostrophes, the two strings being separated by
the arrow symbol (<TT>-></TT>), formed by the ``minus'' and ``greater than''
characters. The rule is terminated by a semi-colon.</P>
<PRE>
TextTransSeq = [ Alphabet ] TransSeq .
Alphabet = NAME .
TransSeq ='BEGIN' < Translation > 'END' ';' /
Translation .
Translation = Source [ '->' Target ] ';' .
Source = STRING .
Target = STRING .
</PRE>
<P>
One such rule signifies that when the source string appears in a text leaf of
the document being translated, the translator must replace it, in the
translated document, with the target string. The source string and the target
string can have different lengths and the target string can be empty. In this
last case, the translator simply suppresses every occurrence of the source
string in the translated document.</P>
<P>
For a given alphabet, the order of the rules is not important and has no
significance because the T language compiler reorders the rules in ways that
speed up the translator's work. The total number of recoding rules is limited
by the compiler as is the maximum length of the source and target strings.</P>
<P>
The recoding rules for symbols and graphical elements are written in the same
manner as the recoding rules for character strings. They are preceded,
respectively, by the <TT>SYMBTRANSLATE</TT> and <TT>GRAPHTRANSLATE</TT> and so
not require a specification of the alphabet. Their source string is limited to
one character, since, in Thot, each symbol and each graphical element is
represented by a single character. The symbol and graphical element codes are
defined along with the <A href="#charcoding">non-standard character
codes</A>.</P>
<BLOCKQUOTE class="example">
<P>
<STRONG>Example:</STRONG></P>
<P>
In a translation schema producing documents destined for use with
the L<SUP>A</SUP>T<SUB><BIG>E</BIG></SUB>X formatter, the Latin
characters``é'' (octal code 351 in Thot) and ``è'' (octal code
350 in Thot) must be converted to their representation
in L<SUP>A</SUP>T<SUB><BIG>E</BIG></SUB>X:</P>
<PRE>
TEXTTRANSLATE Latin
BEGIN
'\350' -> '\`{e}'; { e grave }
'\351' -> '\''{e}'; { e acute }
END;
</PRE>
</BLOCKQUOTE>
</DIV>
</DIV>
<HR>
</DIV>
<DIV class="chapter">
<H1>Language grammars</H1>
<P>
This chapter gives the complete grammars of the languages of Thot. The
grammars were presented and described in the preceding chapters, which also
specify the semantics of the languages. This section gives only the
syntax.</P>
<DIV class="section">
<H2>The M meta-language</H2>
<P>
The language grammars are all expressed in the same formalism, the M
meta-language, which is defined in this section.</P>
<PRE>
{ Any text between braces is a comment. }
Grammar = Rule < Rule > 'END' .
{ The < and > signs indicate zero }
{ or more repetitions. }
{ END marks the end of the grammar. }
Rule = Ident '=' RightPart '.' .
{ The period indicates the end of a rule }
RightPart = RtTerminal / RtIntermed .
{ The slash indicates a choice }
RtTerminal ='NAME' / 'STRING' / 'NUMBER' .
{ Right part of a terminal rule }
RtIntermed = Possibility < '/' Possibility > .
{ Right part of an intermediate rule }
Possibility = ElemOpt < ElemOpt > .
ElemOpt = Element / '[' Element < Element > ']' /
'<' Element < Element > '>' .
{ Brackets delimit optional parts }
Element = Ident / KeyWord .
Ident = NAME .
{ Identifier, sequence of characters
KeyWord = STRING .
{ Character string delimited by apostrophes }
END
</PRE>
</DIV>
<DIV class="section">
<H2>The S language</H2>
<P>
The S language is used to write structure schemas, which contain the generic
logical structures of document and object classes. It is described here in
the M meta-language.</P>
<PRE>
StructSchema = 'STRUCTURE' [ 'EXTENSION' ] ElemID ';'
'DEFPRES' PresID ';'
[ 'ATTR' AttrSeq ]
[ 'PARAM' RulesSeq ]
[ 'STRUCT' RulesSeq ]
[ 'EXTENS' ExtensRuleSeq ]
[ 'ASSOC' RulesSeq ]
[ 'UNITS' RulesSeq ]
[ 'EXPORT' SkeletonSeq ]
[ 'EXCEPT' ExceptSeq ]
'END' .
ElemID = NAME .
PresID = NAME .
AttrSeq = Attribute < Attribute > .
Attribute = AttrID '=' AttrType ';' .
AttrType = 'INTEGER' / 'TEXT' /
'REFERENCE' '(' RefType ')' /
ValueSeq .
RefType = 'ANY' /
[ FirstSec ] ElemID [ ExtStruct ] .
ValueSeq = AttrVal < ',' AttrVal > .
AttrID = NAME .
FirstSec = 'First' / 'Second' .
ExtStruct = '(' ElemID ')' .
AttrVal = NAME .
RulesSeq = Rule < Rule > .
Rule = ElemID [ LocAttrSeq ] '='
DefWithAttr ';' .
LocAttrSeq = '(' 'ATTR' LocalAttr
< ';' LocalAttr > ')' .
LocalAttr = [ '!' ] AttrID [ '=' AttrType ] .
DefWithAttr = Definition
[ '+' '(' ExtensionSeq ')' ]
[ '-' '(' RestrictSeq ')' ]
[ 'WITH' FixedAttrSeq ] .
ExtensionSeq = ExtensionElem < ',' ExtensionElem > .
ExtensionElem = ElemID / 'TEXT' / 'GRAPHICS' /
'SYMBOL' / 'PICTURE' .
RestrictSeq = RestrictElem < ',' RestrictElem > .
RestrictElem = ElemID / 'TEXT' / 'GRAPHICS' /
'SYMBOL' / 'PICTURE' .
FixedAttrSeq = FixedAttr < ',' FixedAttr > .
FixedAttr = AttrID [ FixedOrModifVal ] .
FixedOrModifVal= [ '?' ] '=' FixedValue .
FixedValue = [ '-' ] NumValue / TextValue / AttrVal .
NumValue = NUMBER .
TextValue = STRING .
Definition = BaseType [ LocAttrSeq ] / Constr /
Element .
BaseType = 'TEXT' / 'GRAPHICS' / 'SYMBOL' /
'PICTURE' / 'UNIT' / 'NATURE' .
Element = ElemID [ ExtOrDef ] .
ExtOrDef = 'EXTERN' / 'INCLUDED' /
[ LocAttrSeq ] '=' Definition .
Constr = 'LIST' [ '[' min '..' max ']' ] 'OF'
'(' DefWithAttr ')' /
'BEGIN' DefOptSeq 'END' /
'AGGREGATE' DefOptSeq 'END' /
'CASE' 'OF' DefSeq 'END' /
'REFERENCE' '(' RefType ')' /
'PAIR' .
min = Integer / '*' .
max = Integer / '*' .
Integer = NUMBER .
DefOptSeq = DefOpt ';' < DefOpt ';' > .
DefOpt = [ '?' ] DefWithAttr .
DefSeq = DefWithAttr ';' < DefWithAttr ';' > .
SkeletonSeq = SkeletonElem < ',' SkeletonElem > ';' .
SkeletonElem = ElemID [ 'WITH' Contents ] .
Contents = 'Nothing' / ElemID [ ExtStruct ] .
ExceptSeq = Except ';' < Except ';' > .
Except = [ 'EXTERN' ] [ FirstSec ] ExcTypeOrAttr ':'
ExcValSeq .
ExcTypeOrAttr = ElemID / AttrID .
ExcValSeq = ExcValue < ',' ExcValue > .
ExcValue = 'NoCut' / 'NoCreate' /
'NoHMove' / 'NoVMove' / 'NoMove' /
'NoHResize' / 'NoVResize' / 'NoResize' /
'NewWidth' / 'NewHeight' /
'NewHPos' / 'NewVPos' /
'Invisible' / 'NoSelect' /
'Hidden' / 'ActiveRef' /
'ImportLine' / 'ImportParagraph' /
'NoPaginate' / 'HighlightChildren' /
'ExtendedSelection' .
ExtensRuleSeq = ExtensRule ';' < ExtensRule ';' > .
ExtensRule = RootOrElem [ LocAttrSeq ]
[ '+' '(' ExtensionSeq ')' ]
[ '-' '(' RestrictSeq ')' ]
[ 'WITH' FixedAttrSeq ] .
RootOrElem = 'Root' / ElemID .
END
</PRE>
</DIV>
<DIV class="section">
<H2>The P language</H2>
<P>
The P language is used to write presentation schemas, which define the
graphical presentation rules to be applied to different classes of documents
and objects. It is described here in the M meta-language.</P>
<PRE>
PresSchema = 'PRESENTATION' ElemID ';'
[ 'VIEWS' ViewSeq ]
[ 'PRINT' PrintViewSeq ]
[ 'COUNTERS' CounterSeq ]
[ 'CONST' ConstSeq ]
[ 'VAR' VarSeq ]
[ 'DEFAULT' ViewRuleSeq ]
[ 'BOXES' BoxSeq ]
[ 'RULES' PresentSeq ]
[ 'ATTRIBUTES' PresAttrSeq ]
[ 'TRANSMIT' TransmitSeq ]
'END' .
ElemID = NAME .
ViewSeq = ViewDeclaration
< ',' ViewDeclaration > ';' .
ViewDeclaration = ViewID [ 'EXPORT' ] .
ViewID = NAME .
PrintViewSeq = PrintView < ',' PrintView > ';' .
PrintView = ViewID / ElemID .
CounterSeq = Counter < Counter > .
Counter = CounterID ':' CounterFunc ';' .
CounterID = NAME .
CounterFunc = 'RANK' 'OF' TypeOrPage [ SLevelAsc ]
[ 'INIT' AttrID ] [ 'REINIT' AttrID ] /
SetFunction < SetFunction >
AddFunction < AddFunction >
[ 'INIT' AttrID ] /
'RLEVEL' 'OF' ElemID .
SLevelAsc = [ '-' ] LevelAsc .
LevelAsc = NUMBER .
SetFunction = 'SET' CounterValue 'ON' TypeOrPage .
AddFunction = 'ADD' CounterValue 'ON' TypeOrPage .
TypeOrPage = 'Page' [ '(' ViewID ')' ] /
[ '*' ] ElemID .
CounterValue = NUMBER .
ConstSeq = Const < Const > .
Const = ConstID '=' ConstType ConstValue ';' .
ConstID = NAME .
ConstType = 'Text' [ Alphabet ] / 'Symbol' /
'Graphics' / 'Picture' .
ConstValue = STRING .
Alphabet = NAME .
VarSeq = Variable < Variable > .
Variable = VarID ':' FunctionSeq ';' .
VarID = NAME .
FunctionSeq = Function < Function > .
Function = 'DATE' / 'FDATE' /
'DocName' / 'DirName' /
'ElemName' / 'AttributeName' /
ConstID / ConstType ConstValue /
AttrID /
'VALUE' '(' PageAttrCtr ','
CounterStyle ')' .
PageAttrCtr = 'PageNumber' [ '(' ViewID ')' ] /
[ MinMax ] CounterID / AttrID .
CounterStyle = 'Arabic' / 'LRoman' / 'URoman' /
'Uppercase' / 'Lowercase' .
MinMax = 'MaxRangeVal' / 'MinRangeVal' .
BoxSeq = Box < Box > .
Box = 'FORWARD' BoxID ';' /
BoxID ':' ViewRuleSeq .
BoxID = NAME .
PresentSeq = Present < Present > .
Present = [ '*' ] [ FirstSec ] ElemID ':'
ViewRuleSeq .
FirstSec = 'First' / 'Second' .
PresAttrSeq = PresAttr < PresAttr > .
PresAttr = AttrID [ '(' [ FirstSec ] ElemID ')' ]
[ AttrRelation ] ':' ViewRuleSeq .
AttrID = NAME .
AttrRelation = '=' AttrVal /
'>' [ '-' ] MinValue /
'<' [ '-' ] MaxValue /
'IN' '[' [ '-' ] LowerBound '..'
[ '-' ] UpperBound ']' /
'GREATER' AttrID /
'EQUAL' AttrID /
'LESS' AttrID .
AttrVal = [ '-' ] EqualNum / EqualText / AttrValue .
MinValue = NUMBER .
MaxValue = NUMBER .
LowerBound = NUMBER .
UpperBound = NUMBER.
EqualNum = NUMBER .
EqualText = STRING .
AttrValue = NAME .
ViewRuleSeq = 'BEGIN' < RulesAndCond > < ViewRules >
'END' ';' /
ViewRules / CondRules / Rule .
RulesAndCond = CondRules / Rule .
ViewRules = 'IN' ViewID CondRuleSeq .
CondRuleSeq = 'BEGIN' < RulesAndCond > 'END' ';' /
CondRules / Rule .
CondRules = CondRule < CondRule >
[ 'Otherwise' RuleSeq ] .
CondRule = 'IF' ConditionSeq RuleSeq .
RulesSeq = 'BEGIN' Rule < Rule > 'END' ';' / Rule .
ConditionSeq = Condition < 'AND' Condition > .
Condition = [ 'NOT' ] [ 'Target' ] ConditionElem .
ConditionElem = 'First' / 'Last' /
[ 'Immediately' ] 'Within' [ NumParent ]
ElemID [ ExtStruct ] /
ElemID /
'Referred' / 'FirstRef' / 'LastRef' /
'ExternalRef' / 'InternalRef' / 'CopyRef' /
'AnyAttributes' / 'FirstAttr' / 'LastAttr' /
'UserPage' / 'StartPage' / 'ComputedPage' /
'Empty' /
'(' [ MinMax ] CounterName CounterCond ')' /
CondPage '(' CounterID ')' .
NumParent = [ GreaterLess ] NParent .
GreaterLess = '>' / '<' .
NParent = NUMBER.
CounterCond = '<' MaxCtrVal / '>' MinCtrVal /
'=' EqCtrVal /
'IN' '[' ['-'] MinCtrBound '..'
['-'] MaxCtrBound ']' .
PageCond = 'Even' / 'Odd' / 'One' .
MaxCtrVal = NUMBER .
MinCtrVal = NUMBER .
EqCtrVal = NUMBER .
MaxCtrBound = NUMBER .
MinCtrBound = NUMBER .
Rule = PresParam ';' / PresFunc ';' .
PresParam = 'VertRef' ':' HorizPosition /
'HorizRef' ':' VertPosition /
'VertPos' ':' VPos /
'HorizPos' ':' HPos /
'Height' ':' Extent /
'Width' ':' Extent /
'VertOverflow' ':' Boolean /
'HorizOverflow' ':' Boolean /
'LineSpacing' ':' DistOrInherit /
'Indent' ':' DistOrInherit /
'Adjust' ':' AlignOrInherit /
'Justify' ':' BoolInherit /
'Hyphenate' ':' BoolInherit /
'PageBreak' ':' Boolean /
'LineBreak' ':' Boolean /
'InLine' ':' Boolean /
'NoBreak1' ':' AbsDist /
'NoBreak2' ':' AbsDist /
'Gather' ':' Boolean /
'Visibility' ':' NumberInherit /
'Size' ':' SizeInherit /
'Font' ':' NameInherit /
'Style' ':' StyleInherit /
'Underline' ':' UnderLineInherit /
'Thickness' ':' ThicknessInherit /
'Depth' ':' NumberInherit /
'LineStyle' ':' LineStyleInherit /
'LineWeight' ':' DistOrInherit /
'FillPattern' ':' NameInherit /
'Background' ':' NameInherit /
'Foreground' ':' NameInherit .
'Content' ':' VarConst .
PresFunc = Creation '(' BoxID ')' /
'Line' /
'NoLine' /
'Page' '(' BoxID ')' /
'Copy' '(' BoxTypeToCopy ')' .
BoxTypeToCopy = BoxID [ ExtStruct ] /
ElemID [ ExtStruct ] .
ExtStruct = '(' ElemID ')' .
Distance = [ Sign ] AbsDist .
Sign = '+' / '-' .
AbsDist = IntegerOrAttr [ '.' DecimalPart ]
[ Unit ] .
IntegerOrAttr = IntegerPart / AttrID .
IntegerPart = NUMBER .
DecimalPart = NUMBER .
Unit = 'em' / 'ex' / 'cm' / 'mm' / 'in' / 'pt' /
'pc' / 'px' / '%' .
HPos = 'nil' / VertAxis '=' HorizPosition
[ 'UserSpecified' ] .
VPos = 'nil' / HorizAxis '=' VertPosition
[ 'UserSpecified' ] .
VertAxis = 'Left' / 'VMiddle' / 'VRef' / 'Right' .
HorizAxis = 'Top' / 'HMiddle' / 'HRef' / 'Bottom' .
VertPosition = Reference '.' HorizAxis [ Distance ] .
HorizPosition = Reference '.' VertAxis [ Distance ] .
Reference = 'Enclosing' [ BoxTypeNot ] /
'Enclosed' [ BoxTypeNot ] /
'Previous' [ BoxTypeNot ] /
'Next' [ BoxTypeNot ] /
'Referred' [ BoxTypeNot ] /
'Creator' /
'Root' /
'*' /
BoxOrType .
BoxOrType = BoxID /
[ '*' ] [ FirstSec ] ElemID /
'AnyElem' / 'AnyBox' .
BoxTypeNot = [ 'NOT' ] BoxOrType .
Extent = Reference '.' HeightWidth
[ Relation ] [ 'Min' ] /
AbsDist [ 'UserSpecified' ] [ 'Min' ] /
HPos / VPos .
HeightWidth = 'Height' / 'Width' .
Relation = '*' ExtentAttr '%' / Distance .
ExtentAttr = ExtentVal / AttrID .
ExtentVal = NUMBER .
Inheritance = Kinship InheritedValue .
Kinship = 'Enclosing' / 'GrandFather'/ 'Enclosed' /
'Previous' / 'Creator' .
InheritedValue = '+' PosIntAttr [ 'Max' maximumA ] /
'-' NegIntAttr [ 'Min' minimumA ] /
'=' .
PosIntAttr = PosInt / AttrID .
PosInt = NUMBER .
NegIntAttr = NegInt / AttrID .
NegInt = NUMBER .
maximumA = maximum / AttrID .
maximum = NUMBER .
minimumA = minimum / AttrID .
minimum = NUMBER .
AlignOrInherit = Kinship '=' / Alignment .
Alignment = 'Left' / 'Right' / 'VMiddle' /
'LeftWithDots' .
DistOrInherit = Kinship InheritedDist / Distance .
InheritedDist = '=' / '+' AbsDist / '-' AbsDist .
BoolInherit = Boolean / Kinship '=' .
Boolean = 'Yes' / 'No' .
NumberInherit = Integer / AttrID / Inheritance .
Integer = NUMBER .
LineStyleInherit= Kinship '=' / 'Solid' / 'Dashed' /
'Dotted' .
SizeInherit = SizeAttr [ 'pt' ] / Kinship InheritedSize .
InheritedSize = '+' SizeAttr [ 'pt' ]
[ 'Max' MaxSizeAttr ] /
'-' SizeAttr [ 'pt' ]
[ 'Min' MinSizeAttr ] /
'=' .
SizeAttr = Size / AttrID .
Size = NUMBER .
MaxSizeAttr = MaxSize / AttrID .
MaxSize = NUMBER .
MinSizeAttr = MinSize / AttrID .
MinSize = NUMBER .
NameInherit = Kinship '=' / FontName .
FontName = NAME .
StyleInherit = Kinship '=' /
'Roman' / 'Bold' / 'Italics' /
'BoldItalics' / 'Oblique' / 'BoldOblique' .
UnderLineInherit= Kinship '=' /
'NoUnderline' / 'Underlined' /
'Overlined' / 'CrossedOut' .
ThicknessInherit= Kinship '=' / 'Thick' / 'Thin' .
VarConst = ConstID / ConstType ConstValue /
VarID / '(' FunctionSeq ')' /
ElemID .
Creation = Create [ 'Repeated' ] .
Create = 'CreateFirst' / 'CreateLast' /
'CreateBefore' / 'CreateAfter' /
'CreateEnclosing' .
TransmitSeq = Transmit < Transmit > .
Transmit = TypeOrCounter 'To' ExternAttr
'(' ElemID ')' ';' .
TypeOrCounter = CounterID / ElemID .
ExternAttr = NAME .
END
</PRE>
</DIV>
<DIV class="section">
<H2>The T language</H2>
<PRE>
TransSchema = 'TRANSLATION' ElemID ';'
[ 'LINELENGTH' LineLength ';' ]
[ 'LINEEND' CHARACTER ';' ]
[ 'LINEENDINSERT' STRING ';' ]
[ 'BUFFERS' BufferSeq ]
[ 'COUNTERS' CounterSeq ]
[ 'CONST' ConstSeq ]
[ 'VAR' VariableSeq ]
'RULES' ElemSeq
[ 'ATTRIBUTES' AttrSeq ]
[ 'PRESENTATION' PresSeq ]
< 'TEXTTRANSLATE' TextTransSeq >
[ 'SYMBTRANSLATE' TransSeq ]
[ 'GRAPHTRANSLATE' TransSeq ]
'END' .
LineLength = NUMBER .
BufferSeq = Buffer < Buffer > .
Buffer = BufferID [ '(' 'Picture' ')' ] ';' .
BufferID = NAME .
CounterSeq = Counter < Counter > .
Counter = CounterID [ ':' CounterFunc ] ';' .
CounterID = NAME .
CounterFunc = 'Rank' 'of' ElemID [ SLevelAsc ]
[ 'Init' AttrID ] /
'Rlevel' 'of' ElemID /
'Set' InitValue 'On' ElemID
'Add' Increment 'On' ElemID
[ 'Init' AttrID ] .
SLevelAsc = [ '-' ] LevelAsc .
LevelAsc = NUMBER .
InitValue = NUMBER .
Increment = NUMBER .
ElemID = NAME .
AttrID = NAME .
ConstSeq = Const < Const > .
Const = ConstID '=' ConstValue ';' .
ConstID = NAME .
ConstValue = STRING .
VariableSeq = Variable < Variable > .
Variable = VarID ':' Function < Function > ';' .
VarID = NAME .
Function = 'Value' '(' CounterID [ ':' Length ]
[ ',' CounterStyle ] ')' /
'FileDir' / 'FileName' / 'Extension' /
'DocumentName' / 'DocumentDir' /
ConstID / CharString /
BufferID / AttrID .
Length = NUMBER .
CounterStyle= 'Arabic' / 'LRoman' / 'URoman' /
'Uppercase' / 'Lowercase' .
CharString = STRING .
ElemSeq = TransType < TransType > .
TransType = [ FirstSec ] ElemID ':' RuleSeq .
FirstSec = 'First' / 'Second' .
RuleSeq = Rule / 'BEGIN' < Rule > 'END' ';' .
Rule = SimpleRule / ConditionBlock .
ConditionBlock= 'IF' ConditionSeq SimpleRuleSeq .
SimpleRuleSeq = 'BEGIN' < SimpleRule > 'END' ';' /
SimpleRule .
ConditionSeq = Condition [ 'AND' Condition ] .
Condition = [ 'NOT' ] [ 'Target' ] Cond .
Cond = CondElem / CondAscend .
CondElem = 'FirstRef' / 'LastRef' /
'ExternalRef' /
'Defined' /
'Alphabet' '=' Alphabet /
'ComputedPage' / 'StartPage' /
'UserPage' / 'ReminderPage' /
'Empty' /
'FirstAttr' / 'LastAttr' .
CondAscend = [ Ascend ] CondOnAscend .
Ascend = '*' / 'Parent' / 'Ancestor' LevelOrType .
LevelOrType = CondRelLevel / ElemID [ ExtStruct ] .
CondRelLevel = NUMBER .
CondOnAscend = 'First' / 'Last' /
'Referred' /
[ 'Immediately' ] 'Within' [ NumParent ]
ElemID [ ExtStruct ] /
'Attributes' /
AttrID [ RelatAttr ] /
'Presentation' /
PresRule /
'Comment' .
NumParent = [ GreaterLess ] NParent .
GreaterLess = '>' / '<' .
NParent = NUMBER.
Alphabet = NAME .
RelatAttr = '=' Value /
'>' [ '-' ] Minimum /
'<' [ '-' ] Maximum /
'IN' '[' [ '-' ] MinInterval '..'
[ '-' ] MaxInterval ']' .
Value = [ '-' ] IntegerVal / TextVal / AttrValue .
Minimum = NUMBER .
Maximum = NUMBER .
MinInterval = NUMBER .
MaxInterval = NUMBER .
IntegerVal = NUMBER .
TextVal = STRING .
AttrValue = NAME .
SimpleRule = 'Create' [ 'IN' VarID ] Object
[ Position ] ';' /
'Write' Object [ Position ] ';' /
'Read' BufferID [ Position ] ';' /
'Include' File [ Position ] ';' /
'Get' [ RelPosition ] ElemID
[ ExtStruct ]
[ Position ] ';' /
'Copy' [ RelPosition ] ElemID
[ ExtStruct ]
[ Position ] ';' /
'Use' TrSchema [ 'For' ElemID ] ';' /
'Remove' ';' /
'NoTranslation' ';' /
'NoLineBreak' ';' /
'ChangeMainFile' VarID [ Position ] ';' /
'Set' CounterID InitValue
[ Position ] ';' /
'Add' CounterID Increment
[ Position ] ';' .
Object = ConstID / CharString /
BufferID /
VarID /
'(' Function < Function > ')' /
AttrID /
'Value' /
'Content' /
'Comment' /
'Attributes' /
'Presentation' /
'RefId' /
'PairId' /
'FileDir' / 'FileName' / 'Extension' /
'DocumentName' / 'DocumentDir' /
[ 'Referred' ] ReferredObject .
Position = 'After' / 'Before' .
ReferredObject = VarID /
ElemID [ ExtStruct ] /
'RefId' /
'DocumentName' / 'DocumentDir' .
File = FileName / BufferID .
FileName = STRING .
RelPosition = 'Included' / 'Referred' .
ExtStruct = '(' ElemID ')' .
TrSchema = NAME .
AttrSeq = TransAttr < TransAttr > .
TransAttr = AttrID [ '(' ElemID ')' ]
[ RelatAttr ] ':' RuleSeq .
PresSeq = PresTrans < PresTrans > .
PresTrans = PresRule ':' RuleSeq .
PresRule = 'Size' [ PresRelation ] /
'Indent' [ PresRelation ] /
'LineSpacing' [ PresRelation ] /
'Adjust' [ '=' AdjustVal ] /
'Justify' [ '=' BoolVal ] /
'Hyphenate' [ '=' BoolVal ] /
'Style' [ '=' StyleVal ] /
'Font' [ '=' FontVal ] /
'UnderLine' [ '=' UnderLineVal ] /
'Thickness' [ '=' ThicknessVal ] /
'LineStyle' [ '=' LineStyleVal ] /
'LineWeight' [ PresRelation ] /
'FillPattern' [ '=' Pattern ] /
'Background' [ '=' Color ] /
'Foreground' [ '=' Color ] .
PresRelation = '=' PresValue /
'>' [ '-' ] PresMinimum /
'<' [ '-' ] PresMaximum /
'IN' '[' [ '-' ] PresIntervalMin '..'
[ '-' ] PresIntervalMax ']' .
AdjustVal = 'Left' / 'Right' / 'VMiddle' /
'LeftWithDots' .
BoolVal = 'Yes' / 'No' .
StyleVal = 'Bold' / 'Italics' / 'Roman' /
'BoldItalics' / 'Oblique' /
'BoldOblique' .
FontVal = 'Times' / 'Helvetica' / 'Courier' .
UnderLineVal = 'NoUnderline' / 'UnderLined' /
'OverLined' / 'CrossedOut' .
ThicknessVal = 'Thick' / 'Thin' .
LineStyleVal = 'Solid' / 'Dashed' / 'Dotted' .
Pattern = NAME .
Color = NAME .
PresMinimum = NUMBER .
PresMaximum = NUMBER .
PresIntervalMin= NUMBER .
PresIntervalMax= NUMBER .
PresValue = [ '-' ] PresVal .
PresVal = NUMBER .
TextTransSeq = [ Alphabet ] TransSeq .
Alphabet = NAME .
TransSeq = 'BEGIN' < Translation > 'END' ';' /
Translation .
Translation = Source [ '->' Target ] ';' .
Source = STRING .
Target = STRING .
</PRE>
</DIV>
<HR>
</DIV>
<DIV class="chapter">
<H1><A name="charcoding">Character coding</A></H1>
<DIV class="section">
<H2>Characters</H2>
<P>
The characters of the Latin alphabet follow the encoding defined in the ISO
8859-1 (ISO Latin 1) standard. The characters of the Greek alphabet follow
the encoding defined by Adobe for its Symbol font (Adobe FontSpecific).</P>
<P>
Characters whose octal code is greater than 0200 are written in the form of
their octal code preceded by a backslash character (``\''). For example, the
French word Résumé is written <TT>R\351sum\351</TT>.</P>
<P>
To the ISO 8859-1 encoding four characters with the following codes have been
added:<BR><TT>212</TT>: line break<BR><TT>240</TT>: sticky
space<BR><TT>201</TT>: thin space<BR><TT>202</TT>: en space</P>
<P>
The <TT>212</TT> character is a ``line break'' character which forces a line
break. The <TT>240</TT> character is a ``sticky space'', which cannot be
replaced by a line break.</P>
</DIV>
<DIV class="section">
<H2><A name="symbolcoding">Symbols</A></H2>
<P>
The table below gives the codes for the symbols of Thot. Symbols can be used
in presentation schemas constants and in transcoding rules of translation
schemas. Each symbol is represented by a single character.</P>
<UL>
<LI><TT>r</TT>: a radical
<LI><TT>i</TT>: a simple integral
<LI><TT>c</TT>: a curvilinear integral
<LI><TT>d</TT>: a double integral
<LI><TT>t</TT>: a triple integral
<LI><TT>S</TT>: the summation symbol
<LI><TT>P</TT>: the product symbol
<LI><TT>U</TT>: the union symbol
<LI><TT>I</TT>: the intersection symbol
<LI><TT>></TT>: a right arrow
<LI><TT><</TT>: a left arrow
<LI><TT>^</TT>: an up arrow
<LI><TT>V</TT>: a down arrow
<LI><TT>(</TT>: an opening parenthesis
<LI><TT>)</TT>: a closing parenthesis
<LI><TT>{</TT>: an opening brace
<LI><TT>}</TT>: a closing brace
<LI><TT>[</TT>: an opening bracket
<LI><TT>]</TT>: a closing bracket
</UL>
</DIV>
<DIV class="section">
<H2>Graphical elements</H2>
<P>
The table below gives the codes for the graphical elements of Thot. These
elements can be used in presentation schemas constants and in transcoding
rules of translation schemas. Each graphical element is represented by a
single character.</P>
<UL>
<LI><TT>c</TT>: an ellipse inscribed in the box
<LI><TT>R</TT>: a rectangle which is the shape of the box
<LI><TT>C</TT>: a rectangle with rounded corners
<LI><TT>t</TT>: a horizontal line along the upper side of the box
<LI><TT>h</TT>: a horizontal line as wide as the box and placed in its middle
<LI><TT>b</TT>: a horizontal line along the lower side of the box
<LI><TT>></TT>: a right arrow as long as the box's width and in its middle
<LI><TT>></TT>: a left arrow as long as the box's width and in its middle
<LI><TT>l</TT>: a vertical line on the left side of the box
<LI><TT>v</TT>: a vertical line as tall as the box and placed in its middle
<LI><TT>r</TT>: a vertical line on the right side of the box
<LI><TT>^</TT>: an up arrow as tall as the box and in its middle
<LI><TT>V</TT>: a down arrow as tall as the box and in its middle
<LI><TT>/</TT>: The southwest/northeast diagonal of the box
<LI><TT>\</TT>: the northwest/southeast diagonal of the box
<LI><TT>O</TT>: The northwest/southeast diagonal of the box with an arrowhead
at the top
<LI><TT>e</TT>: The northwest/southeast diagonal of the box with an arrowhead
at the bottom
<LI><TT>E</TT>: The southwest/northeast diagonal of the box with an arrowhead
at the top
<LI><TT>o</TT>: The southwest/northeast diagonal of the box with an arrowhead
at the bottom
<LI><TT>space</TT>: a transparent element
<LI><TT>P</TT>: a rectangle with round corners and a horizontal bar at the top
<LI><TT>Q</TT>: an ellipse with a horizontal bar at the top
<LI><TT>L</TT>: a lozenge
<LI><TT>W</TT>: the upper right corner
<LI><TT>X</TT>: the lower right corner
<LI><TT>Y</TT>: the lower left corner
<LI><TT>Z</TT>: the upper left corner
<LI><TT>p</TT>: a polygon
<LI><TT>S</TT>: an open broken line
<LI><TT>N</TT>: an open broken line with an arrow head at start
<LI><TT>U</TT>: an open broken line with an arrow head at the end
<LI><TT>M</TT>: an open broken line with two arrow heads
<LI><TT>s</TT>: a closed curve
<LI><TT>B</TT>: an open curve
<LI><TT>F</TT>: an open curve with an arrow head at start
<LI><TT>A</TT>: an open curve with an arrow head at the end
<LI><TT>D</TT>: an open curve with two arrow heads
</UL>
</DIV>
</DIV>
</BODY>
</HTML>
Webmaster
![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to languages.html CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [Public] / Amaya / doc