Filetype PDF | Posted on 03 Feb 2023 | 2 years ago
Authentication
digital resources
135x Filetype PDF File size 0.80 MB Source: tug.org
An Object-Oriented Programming System in TEX
William Baxter
Superscript, Box 20669, Oakland, CA 94620-0669, USA
web@superscri pt. corn
Abstract
This paper describes the implementation of an object-oriented programming sys-
tem in TEX. The system separates formatting procedures from the document
markup. It offers design programmers the benefits of object-oriented program-
ming techniques.
The inspiration for these macros comes from extensive book-production
experience with W&X.
This paper is a companion to Arthur Ogawa's "Object-Oriented Programming,
Descriptive Markup, and TEX".
The macros presented here constitute the fruit of a a new element. This is not difficult to accomplish ad
struggle to produce sophisticated books in a com- hoc. The design programmer can implement prefur
mercial environment. They run under either plain commands modifying the default behavior of a sub-
TEX or LATEX, but owe their primary inspiration to sequent command or environment, add additional
LATEX, especially in the separation of logical and vi- optional arguments, or create new commands and
environments. But these solutions demand
sual design. The author hopes that future TEX-based irnmedi-
document production systems such as LATEX^ and ate intervention by the design programmer and also
NTS will incorporate these techques and the expe- require that the user learn how to handle the special
rience they represent. cases.
Throughout this paper we refer to book produc- A markup scheme in which optional attributes
tion with accompany elements provides a simple, consistent,
WX. Many of the comments apply equally
and extensible mechanism to handle
well to other TEX-based document processing envi- ths type of pro-
ronments. duction difficulty. Instead of the standard LATEX en-
vironment markup
Design and Production Perspectives \begi n{theorem} [OOPS, A Theorem]
Certain problems routinely crop up during book pro- ...
duction with LATEX. The majority fall into two general \end{theorem)
categories: those related to the peculiarities of a par- we write
ticular job and those regarding the basic capabilities \open\theorem{
of the production system. \ti tl e{OOPS, A Theorem)
Peculiar documents. Strange, and sometimes even 1
bizarre, element variants often occur within a single . . .
document. Without extremely thorough manuscript \cl ose\theorem
analysis these surprise everybody during composi- Each attribute consists of a key-value pair, where the
tion, after the schedules have been set. The author key is a single control sequence and the value is a
received the following queries during production of group of tokens. The pair resemble a token register
a single book: assignment or a simple debtion.
1. What is the proper way to set Theorem 2.1' after The \open macro parses the attributes and
Theorem 2.1? makes them avdable to the procedures that actu-
ally typeset the element. Thus any element instan-
2. Small icons indicating the field of application tiated with \open. . .\close allows attributes. Fur-
accompany certain exercise items. How do we thermore, any such element may ignore (or simply
accommodate these variations? complain about) attributes it doesn't understand.
3. Ths book contains step lists numbered Step 1, For example, if an exercise item coded as an element
Step 2, . . . , and other lists numbered Rhubarb 1, requires both application and difficulty attributes, it
Rhubarb 2, . . . How do we code these? can be coded like this:
Each variation requires the ability to override the de-
fault behavior of the element in question, or to create
TUGboat, Volume 15 (1994), No. 3 -Proceedings of the 1994 Annual Meeting
William Baxter
\difficulty(3.4} TEX or IN$X requires too much skill for most produc-
I tion houses to maintain. The macros described in
. . . the remainder of ths paper address ths deficiency
\cl ose\i tem through the application of object-oriented program-
Production can proceed, with the new attribute in ming techniques to the problem of design implemen-
place but unused. At some later time the design tation.
programmer can modify the procedures that actually The OOPS approach
typeset the element to make use of the new attribute.
In the case of the rhubarb list, we can use an Before delving too far into the actual workings of the
attribute of the list element to modify the name of system we deliver the propaganda.
the items: The object-oriented programming paradigm fits
the needs of document production extremely well.
A document element is an object, and its type is a
class. Thus a theorem element is an object of class
theorem. Deriving one element type from another
and overriding some behavior of the new element
Basic capabilities. Complex designs require macro is a subclassing operation. For example, a lettered
packages far more capable than those of standard list class may be derived from a numbered list class.
EQX. The designs require color separation, large Attributes correspond to instance variables. The use
of the
numbers of typefaces, letterspacing, complicated ti tl e attribute in the theorem example above
page layouts, backdrop screens and changebars, in- demonstrates thls. The W&X notion of a document
teraction of neighboring elements, and other "inter- style resembles a class library.
esting" aspects of design. A production system must After defining the OOPS markup, the remainder
address all of these aspects of design in order to re- of this section describes a generic class library. A de-
main viable in a commercial setting. And it must do sign programmer implements a particular document
so in a cost effective manner. design using this standard set of element classes,
In their desire to reduce the total and initial possibly adding new classes as needed. The reader
costs of a formatting package, production houses should consider a class library as an alternative to a
ask: UTEX'S document style or document class.
1. How do we use these macros with another man- OOPS markup. The OOPS markup for this system
uscript that employs different markup, say, works somewhat like the \open and \close markup
scheme presented above. The
SGML? \@i nstanti ate com-
2. When will we be able to write our own macro mand creates an element of a particular class. It
packages? takes two arguments: the name of the class (or par-
ent class) and the list of instance attributes. The com-
The first question has a relatively simple answer. mand \@anni hi 1 ate destroys an element. It takes
We define a generic markup scheme (very simdar to the element class to destroy as its single argument.
\open. . .\close). Design programmers implement So, reiterating the theorem example from above, the
their formatting procedures assuming that all doc- design programmer assumes the following style of
uments use this markup. A separate layer of pars- markup:
ing macros translates the markup that actually ap- \@i nstantiate\theorem{
pears in the document into the generic markup. We \ti tl e{OOPS, A Theorem}
call the generic markup scheme the OOPS markup. \number{2.1'3
A design implemented behind the OOPS markup is
a formatter. The markup scheme that actually ap- 1
pears in the document is the document markup. A . . .
set of macros that translate from a particular docu- \@anni hilate\theorem
ment markup into OOPS markup is a This sample code instantiates an element of class
face.
The OOPS markup constitutes an interface be- theorem, overriding the title and number at-
tween formatter and face, whlle the face bridges the tributes. After some other processing it then de-
gap between document markup and OOPS markup. stroys the the theorem instance.
The same formatter can be used with a hfferent face, We pause here to provide some clues to the
and the same face with a different formatter. This reader about how TEX sees commands, elements,
newfound ability to reuse a formatter code makes classes, and attributes. A command is a control se-
TEX far more attractive to commercial typesetters. quence destined for execution by TEX. In contrast,
a
The second question poses a far greater puzzle. class, element, or attribute is a string conveniently
At present, implementing a complex book design in represented as a control sequence name. The OOPS
332 TUGboat, Volume 15 (1994), No. 3 -Proceedings of the 1994 Annual Meeting
An Object-Oriented Programming System in TEX
system neither defines nor executes these control se- cute \@new at some point, but can carry out other
quence names. Instead, it derives a command name processing before and after executing \@new. The
from an element :attri bute or class: attri bute @precl ass and @subcl ass attributes are subclass-
pair. One can think of attribute as a shorthand ing hooks used, for example, to set up a default num-
for command derived from the cl ass : att ri bute bering scheme or allocate a class counter.
or el ement : att ri bute pair. Thus the phrase exe- In the example above, \@class first clones the
cute an attribute steplist class as rhubarblist. If the name at-
means execute the command derived
from an tribute exists in the rhubarb1 i st class then it is al-
attri bute:element or attri bute:class
pair. tered, otherwise it is added.
The
Returning to the example, the \@i nstanti ate \@cl ass and \@new commands actually al-
command creates an element of class theorem. It low multiple inheritance. The parent argument to
copies each attribute of the theorem class for the ex- \@class may consist of one or more class names.
clusive use of this particular element and overrides The @class attribute is always executed from the
the meaning of the title and
number attributes. Af- head parent, the first parent in the list. With multiple
ter instantiation the hidden control sequence corre- inheritance two parents may contain conflicting def-
sponding to the element : ti tl e attribute expands initions of the same attribute. Attributes are passed
to "OOPS, A Theorem". from parent to child on a first-come-frrst-served ba-
Adopting the OOPS markup as the interface be- sis. The child inherits the meaning of an attribute
tween formatting procedures and document pars- from the first parent class containing that attribute.
ing routines is not terribly significant. But combin- The defmtion of the @class attribute in most
ing it with object-oriented programming techniques classes is identical to that of @element because it is
results in a powerful and flexible system for creat- inherited without overriding. But this system per-
ing new element classes. Inheritance plays the key mits overriding the @class attribute just like any
role. If one element class functions with the stan- other.
The design programmer uses
dard markup then new elements derived from it in- \@cl ass to create
herit this ability. a class for each element. During document process-
Subclassing. The @element class is the common ing these classes are instantiated as document ele-
ancestor of all classes giving rise to document ele- ments.
ments. Thls class supports the OOPS markup de- Instantiation. To instantiate an element the com-
\Qi nstanti ate parses the OOPS markup and
scribed above. It also supports subclassing oper- mand
ations, allowing the design programmer to derive squirrels away its arguments in special locations.
from it new element classes that support OOPS It then executes the @i nstanti ate attribute from
markup. the class (from theorem in the above example). A
The \@class command derives one element pseudo-code defmtion of the @i nstanti ate at-
@element class is:
class from another. In the following example we de- tribute in the
rive the rhubarb list from the steplist. @element :@i nstanti ate=
\@class\rhubarbl i st\stepl i st{
\name{Rhubarb}
1
The arguments to \@class are the new class name
(or chdd class), the name of the parent class, and the
list of attributes that override or supplement those The @prei nstantiate attribute is analogous to
of the parent. The \@class command parses its ar- the @preclass attribute. It carries out process-
guments, stores them in standard places, and then ing that must precede the creation of the new el-
executes the ement. The @i ni ti a1 i ze attribute performs pro-
@cl ass attribute from the parent class.
The pseudo-code defimtion of the attribute @class cessing required by the newly-created element. The
in the @el ement class is: @startgroup attribute determines whether the ele-
@element :@cl ass= ment is subject to TEX'S grouping mechanism. It usu-
empty, resulting in an ungrouped element (like the
J6&X document environment). The @start attribute
performs start processing for the particular element,
The \@new command carries out the low-level pro- in rough correspondence to the second required ar-
cessing for subclassing. It takes the new class gument to the
name, parent class name, and attribute list parsed LATEX command \newenvi ronment.
by \@class out of storage and constructs the new As with subclassing, the \@new command per-
class from them. Every @class attribute must exe- forms the low-level instantiation function. It con-
structs the new element from the material stored
TUGboat, Volume 15 (1994), No. 3 -Proceedings of the 1994 Annual Meeting 333
William Baxter
away by \@i nstanti ate. This brings to light one ba- of properly adjusting the vertical space around I&&X
sic implementation decision: a class is simply an ob- environments routinely provokes severe consterna-
ject created with
\@cl ass, while an element is an ob- tion in production managers who care about quality.
ject instantiated with \@instantiate. The @block class unifies the various mech-
The
\@anni hi 1 ate command parses class name anisms for inserting space above and below any
and stores it in a standard location. It then executes block element with four attributes: @abovespace,
the @anni hi 1 ate attribute from the most recent in- @be1 owspace, abovespace, and be1 owspace. The
stantiation of that element. A pseudo-code defmtion first two are for the design programmer, and consti-
of @anni
hi 1 ate in the @element class is: tute the default space above and below the element.
@element The latter two are deviations added to the first two
: @anni hi 1 ate=
in the obvious fashion. They are for the convenience
of the final page makeup artist.
Each block element class uses these attributes
The @end attribute corresponds to the third required in the appropriate manner. An ordnary block ele-
argument to the LATEX \newenvi ronment command ment, such as a paragraph, may insert space above
and carries out end processing. The @endgroup at- and below using \addvspace. But a display math el-
tribute matches estartg roup, and usually expands ement would instead use \abovedi spl ayski p and
to \be1 owdi spl ayski p. In either case the user is al-
\endgroup. Like @startgroup it can also be given ways presented with the same mechanism for ad-
an empty expansion to eliminate grouping. justing this space: the attributes abovespace and
The \@free command provides the low-level be1 owspace. Furthermore, a class library can in-
mechanism for destroying an element instance, com- clude the code to handle the most common block el-
plementing \@new. It operates on the element name ements. Therefore the design programmer can work
parsed by \@anni hi 1 ate, cleaning up the remains of exclusively with the
the now-defunct object. At some point @abovespace and @be1 owspace
eanni hi 1 ate attributes in the majority of cases.
must execute \@free, but other processing may pre- A block element may also insert penalties into
cede or follow such execution. a vertical list above and below its content. It car-
In conclusion, the @el ement class contains the ries attributes @abovepenal ty, @be1 owpenal ty,
following attributes: @cl ass, @precl ass, @subcl ass, abovepenal ty, and be1 owpenal ty that serve as
@instantiate, @prei nstanti ate, @i ni ti a1 ize, penalty analogues to the above and below space at-
@startgroup, @start, @anni hi 1 ate, @endgroup, tributes.
and @end. The \@class command derives new el- Block elements often require different margins
ement classes from old. The \@instantiate com- than their surroundings. For example, a design may
mand creates a new instance of a class as a document call for theorems, lemmas, and proofs to indent at
element,
whlle \@anni hi 1 ate destroys an element. each side. Furthermore, the justification may change
Both \@cl ass and \@i ns tanti ate share an under- from block to block. Block elements carry the at-
lying mechanism. tributes lefti ndent, riqhti ndent, leftjustify,
The class library. What good is the ability to derive and right
j usti fy. hel left and right indentatidn
one element class from another? It forms the basis settings measure the relative offset from the pre-
for a class library that can replace a LATEX document vailing margins, whereas the justification is an ab-
style. We now describe one such class library. solute setting. Again, each block element makes ap-
This class library is founded on the @element propriate use of these attributes. Typically these at-
class described above. All classes are ultimately de- tributes contribute to the values of \l eftski p and
rived from
@el ement using \@cl ass to add new at- \rightski p, with the fixed portion of the glue corn-
tributes as needed. We describe block elements, ing from the "indent" attribute and the stretch and
paragraphs, counting elements, listing elements, sec- shrink coming from the "justify" attribute. In ths
tion elements, and independent elements. way they effectively decompose these \l eftski p
A
block element contributes to the vertical con- and \ri ghtski p, demonstrating that we are not tied
struction of the page. Examples include sections, directly to the model that TEX provides.
theorems, tables, figures, display equations, and Paragraphs are block elements. In the author's
paragraphs. We interpret the common features of class library they are ungrouped in order to avoid
block elements as attributes in the class @block. placing
unnecessary burdens on the underlying TEX
Vertical space separates each block from its system, and the save stack in particular. Thls class
surroundings. During book production, final page library also uses explicit paragraph instantiation as
makeup inevitably requires manual adjustment of the p element, in its most radical departure from
the space around certain blocks. Strictly speak- QX. With this approach we can disable TEX'S au-
ing, this violates the principle of purely descriptive tomatic insertion of \par at every blank line. This
markup, but the need is inescapable. The difficulty
334 TUGboat, Volume 15 (1994), No. 3 -Proceedings of the 1994 Annual Meeting
no reviews yet
Please Login to review.
