With UTEX into the Nineties

Fachbereich Mathematik
Universitat Mainz
Staudinger Weg 9
D-6500 Mainz
schoepfQdmznat51.bitnet

Electronic Data Systems(Deutschland) GmbH
Eisenstrafie 56
D-6090 Riisselsheim
qzdmgnQdrueds2.bitnet

Institut fiir Physik
Universitat Maim
Staudinger Weg 7
D-6500 Mainz
schoepf Qdmznat51 b i t n e t

ABSTRACTDuring the last three years, UT$ has spread widely, even into such new fields as
business applications. The fact that there are new classes of users forces one to reconsider
the UTEX implementation and some of its features. Within a few years, IATG 2.09 alone
will not be sufficient to satisfy the increasing needs of its users. As a consequence one of theimportant characteristics of the UT$ concept - the possibility of exchanging documents- is in danger of being sacrificed on the altar of local changes and enhancements.
Starting from these considerations and from our experiences of several years of IAT$
support, we will present a proposal for a re-implementation of U T G . This new version
would not only preserve the essential features of the present user interface (in order to becompatible with old UT$ files), but also take into account already formulated requests,
as well as future developments.

1.

Introduction

During the last several years, UTEX has become a widely used tool for typesetting documents. Its
advantages over WYSIWIG systems as well as over plain TEX - logical design and high-level commands
for formatting issues - allow even the inexperienced typesetter (author) to easily produce readable
output. Especially for author groups, the concept of logical design is essential to ensure uniformity of
their work.
At least in theory, JAT$ is a markup language which enables the users to specify their input aslogical parts, e.g., to mark a text fraction as a "quotation" or as a "labeled list" instead of supplying
formatting commands such as "indent the next three lines and start with a bullet".
The translation into formatting commands, i.e.,
primitives, is restricted from use (again, atleast in theory) in the source file. It will take place instead, unnoticed by the user, in one of several
style files which should be applicable to the same input source producing different layouts. UTEX itself
provides four different prototype styles ( a r t i c l e , report, book and l e t t e r ) which should be used for
different types of input sources, i.e., should not be interchanged. This contradiction at a first glance(one can't switch between a r t i c l e and r e p o r t for example) is the first (of many) misunderstandingsfor UTEX users and amateur style designers.
TUGboat, Volume 10 (1989), No. 4-

1989 Conference Proceedings681

Since there is only one officially supported document style for each type of input, TJ$X users withplain TEX experience often find themselves unable to produce a desired layout with LATEX. So, after@ even if they then have to face other problems
some unsuccessful attempts, they return to plain T(such as cross-references, etc.) which are easily provided in a markup language such as LATEX.
In this case the root of the problem is the fact that most of the LAT$ Interfaces are poorly
documented so that even TEX experts might have trouble designing an offset layout style for example,
which could be used instead of the standard report style. The result is that LATEX documents all lookalike because all existing document styles are either unusable (because of many bugs), or they are only
variants of the prototype styles, without noticable differences.

2.

The UTEX User Interface - or Essential Features of BTEXFor every type of document UT$ provides a set of high-level formatting commands which themselves
are defined with the help of internal macros. This internal code is highly modular, often ingenious,'
and allows a wide variety of layouts if the style designer is sficiently familar with the interfaces.
On the surface, UTEX demonstrates a thought-out concept too: similar situations require similar
syntax, unusual cases are hidden behind optional arguments . . . But that isn't all. As a standard in
all applications (but with different layouts) LAT$ provides:
automatical generation of contents listings
a powerful cross-referencing mechanism with symbolic names. This allows insertion, deletionand movement of text blocks without re-arranging the equation numbers, etc.
the possibility of typesetting only parts of the document without losing cross-references, countervalues, etc.
a general float mechanism for automatic placement of figures, tables, etc. independently of eachother (but with each class preserving its order)
in conjunction with BIBT$ and Makelndex, it has powerful tools for automatic creation ofindex and bibliography entries2
fully implemented size changing commands for several types of fonts
a general mechanism for switching page layouts (running headings, etc.)
So, why not use LAT#?

3.

This question leads us to our next topic.

Limitations of UTEX Version 2.09

Limitations to the current UT$ version can be divided into several groups, which we will discuss
separately, giving examples as we go along.

Implementation Disasters
This is where most of our examples are located. In a way it is also the group of problems which are
the easiest to solve: just learn from the mistakes Leslie Lamport made but use all his good ideas.
3.1

Fragile commands
Maybe the most troublesome concept in this category is the classification of commands into robust andfragile ones. At the bottom of page 23 the LATEX book says:
The argument of a sectioning command may be used for more than just producing thesection title; it can generate a table of contents entry and a running head at the topof the page. [. . . ] When carried from where it appears in the input file to the otherplaces it is used, the argument of a sectioning command is shaken up quite a bit. SomeUT$ commands are fragile and can break when they appear in an argument that is
shaken in this way. Fragile commands are rarely used in the argument of a sectioning'Clearly not all parts of UT@ are well implemented. But the overall concept is wisely chosen and this isn't affectedby design or implementation bugs in its modules.
'At a site with an up-to-date I4W installation, both programs should be available. Unfortunately, this is often not
the case.

682

TUGboat, Volume 10 (1989), No. 4-

1989 Conference Proceedings

command. [. . .] On the rare occasions when you have to put a fragile command in asection title, you simply protect it with a \protect command.
And later on (p. 24):
An argument in which fragile commands need \ p r o t e c t will be called a moving argument. Commands that are not fragile will be called robust. For any command [. . .] I
will indicate whether it is robust or fragile. Except in special cases [. . .] a \protect
command can't hurt, so it is almost always safe to use one when you're not sure if it'snecessary.
Isn't that easy? Unfortunately not, because a broken command will produce a totally unintelligible
error message and, to make the chaos perfect, not only could this error occur at a different location, it
is also possible that the error will not vanish when the missing \ p r o t e c t is finally discovered. This ishell for novice UTEX users, but even experts are shaken quite a bit if they commit this sin.
The \protect is used to suppress unwanted expansions which are the reasons for the errors mentioned above. This is the wrong design decision: it would be better to suppress all expansions bydefault, and allow the user to expand single macros if there is need for it.
UTEX error recovery
This part of the implementation can be summarized in a single statement: there is none. Actually
there are several situations where the UT$ error routine is triggered but the recovery mechanism
isn't very powerful. On its own, this poses no problems because one can adopt the philosophy "understand the error, correct the source and re-run", but unfortunately the error help messages aren't very
enlightening:
You're i n t r o u b l e here. Try typing <return> t o proceed.
If t h a t doesn't work, type X <return> t o q u i t .

Well, we certainly know we're in trouble when we see a whole page of error messages coming fromW ' s ~ t o m a c h and, ~ instructions on how to turn off the computer and go home: that isn't what theuser expects to get when he or she enters 'H' (for help) after a UTEX error.
The error messages themselves are often simply wrong; for example, the input

produces the error
Something's wrong--perhaps

a missing \itemIn nine out of ten cases this error isn't caused by a missing \item so the user doesn't know what tocorrect - in this case the c e n t e r environment expects text, i.e., something in horizontal mode, andnot just a blank line. Looking in the manual helps a little bit, because there the error messages are
explained in greater detail, but all in all the error messages produced by UTfi are a mess from theuser's point of view.

The generic list environment
The generic list environment is one of the central modules of the UTfi implementation. It is usedinternally by most standard environments provided by UT$; even environments such as center are
handled as a special kind of list (with an empty \item command).
To allow for such a variety of applications, the list environment has nearly 20 parameters andswitches which can be manipulated to change the layout. Additionally the default values for theseparameters (as defined in the document style file) depend on the level of nesting; that is, the document
style may provide different default spacing for lists within lists.
314T$'s tendency to produce horrible-looking error listings is actually a TEX problem which should be listed under" W n i c a l limitations". A large macro package such as UT$ is bound t o have many expansion levels and there is no
possibility of suppressing the intermediate part in the stack history whenspots an error. In our opinion there should
be a T@ \tracing.. . command t o control the amount of history listing.

TUGboat, Volume 10 (1989), No. 4-1989

Conference Proceedings

683

But there are also a few implementation problems:
An actual conceptual bug was the decision to add the value of \parskip to all vertical spacing
parameters, even when it is used in places where no paragraph ends.
This means that changing this parameter influences the layout in unexpected places, which
in turn means that other parameters must be adjusted unnecessarily to compensate for thisundesired side effect.
There is also the problem that the \parskip parameter is user-accessible while the affectedparameters are only changeable in a style file. The user can change the \topsep parameter, forexample, but its default value, define d in the style file, will be restored later on.
The resetting of parameters to their default values if nothing else is specified is somewhat
arbitrary. Some of the important parameters (i.e., the penalty values for page breaking before
and after the list) get their values from the surrounding list which is more than a nuisance fora style d e ~ i g n e r . ~Another implementation decision makes it impossible to define lists with page-wide labels, i.e.,with labels placed on a line by themselves. Those lists cannot be nested properly (see, for example, comments in the article about the implementation of the extended theorem environmentPI).
As U T S is used in more and more fields the need for an even more general list environment isincreasing every day.
3.2 Design Limitations
It is certainly not possible to draw a sharp line between implementation disasters and design limitations.
The former are problems introduced when the macros were written, the latter come from decisions oromissions made during the design phase. Nevertheless, these two phases often go with each other.

Font selection
the method of
One of these limitations was Leslie Lamport's decision to take over from plain
selecting different typefaces: he arranged fonts in a two-dimensional grid, one dimension specifying thesize, the other one the typeface. This was reasonable at the time it was implemented as there were
only a few different typefaces for use with T)$. In the meantime, however, more and more fonts havebecome available, rendering the above design decision inadequate. For example, it is not possible forthe user to switch between Knuth's fonts and the resident fonts of a Postscript printer in a transparent
way.
The list environment
In spite of its generality, the list environment has some conceptual weaknesses:
0 There is no possibility of generating a run-in list, i.e., a list where the first item runs into thepreceding text. This feature is provided inMore generally, since the layout of the standard list types is fixed by the document styleselected, there is no way for the user to select different kinds of layouts for the same type oflists (e.g., enumerated or itemized lists) without defining his own environments. It would bebetter to provide a way to speclfy attributes such as "compact", "stream" (see, for example[17]), "run-in", etc.
0 The vertical spacing before and after lists is controlled by the same parameter.
0 The vertical space preceding the first item does not depend on the length of the last line of thepreceding paragraph (as is the case for displayed equations).

M-m.

Attribute concept
I 4 T g does not allow the user to specify attributes as, for example, Script-DCF does. However, thisconcept is worth being considered for at least partial inclusion in I 4 T S (see previous subsection).
4As an unpleasant result the UT$ f l e q n style option (which causes displayed equations to be typeset flush left
instead of t h e usual centering) favours pagebreaks just before displayed equations. (This bug is corrected in the UTfi
version of 24 May 89.)684

TUGboat, Volume 10 (1989), No. 4-

1989 Conference Proceedings

Text-producing arguments
Themechanism for scanning macro arguments fixes the \catcodes of the token it reads. As aresult, certain UT# commands (such as \verb) cannot be used inside \parboxes, \footnotes, etc.
This can be avoided using a more elaborate scheme; see for example the \footnote implementationin plain TEX [3, p. 3631 or the article about chapter mottos [18].
Support for mathematics
In addition to the math features provided by plain 'I)$, UTEX offers only the eqnarray and array environments. For typesetting mathematical papers with UT# this is certainly not sufEcient. AM-TjjX
provides the necessary features; however, inclusion of these into UT# has not been done yet.5 Instead,various people have written unpublished style options, each implementing limited subsets.

array and t a b u l a r
UTfils t a b u l a r environment is a sophisticated tool for typesetting alignments. That means that you
master to "know how to make ruled tables" [3, p. 2451. On the other hand several
need not be a 'I@
easy-to-implement features are not provided. See for example the new implementation described in[5, 61.
Pictures
To draw picture diagrams UTEX offers mostly basic positioning commands that should actually be
used internally to define high-level interfaces. Examples of such interfaces are given in [13, 161.
The output routine
The UTEX output routine is a very complex and sophisticated module that offers a wide variety ofpossibilities for page make-up. However, certain layout decisions, such as special placement of footnotes
and floats, cannot be implemented in style files without a re-definition of U T G 7 sinternal macros. Thisposes problems of compatibility. See also Section 4.
3.3 Unknown Interfaces
As we have already noted, many interfaces are not properly documented. This results in unnecessarily complicated solutions to certain layout problems. Even worse: sometimes people are led to theconclusion that there is no solution at all!
Such problems can often be solved easily by the internal UTEX macros used in the right way. As an
example, consider an offset layout where all section headers are to extend into the left margin that itself
is wide enough to hold them. This is provided by the generic sectioning command \ @ s t a r t s e c t i o nthat allows an explicit indentation parameter to be specified. If you give a negative value to it, you
end up with section headers that stick out to the left.

3.4 w n i c a l Limitations
In this group we gather limitations caused by the TjjX program itself. Probably the most severe
limitation comes from W ' s insert mechanism. After prematurely ejecting a page (so that the output
routine can look at its contents), inserted material is removed from the main vertical list and gathered
into certain boxes. It is therefore not possible to re-insert the page contents unchanged. This makes
it nearly impossible to balance the height of several columns when insertions such as footnotes or
floats are involved [9]. Other w n i c a l problems arise from the way TEX inserts penalties, or breaks
paragraphs into lines.

4.

New Demands

When asked their opinion, many UTEX users reply:"UTEX is a very fine thing but this (. . . ) and that is missing."

m-w

his situation has now been remedied; the American Mathematical Society will be releasing anstyle filewhich will be an option for use with any T4Tg styie file. There will also be versions of book.sty and article.sty, implementing book and journal styles defined by the AMS. This information comes courtesy of Regina Girouard, Composition
Services Manager of the AMS -Ed.

TUGboat, Volume 10 (1989), No. 4-

1989 Conference Proceedings685

If we ignore those requests that can be satisfied by reading the manual, we are left with three groupsof wishes:
Features that can be implemented in the current version of UTEX. Here we have the problem
that there are too few people who know the internal structure and interfaces sufficiently wellto do it. These interfaces are poorly documented, and misunderstandings and misuse of thesecan lead to catastrophic results. Even if this is done correctly there remains the problem ofcompatibility of the different style options.
0 Features where the necessary interfaces are missing. Here one needs to change the internal
macros of UTEX to implement them.
Totally new requirements that lead to large-scale changes to the code or even to the concepts.
@ itself is not able to handle
Even worse: some things cannot be implemented at all because T
them.
Instead of listing the numerous requests we will give a few examples.
4.1 Easy Implementable Features
We have already talked about the offset style problem. Other examples for requests which can be solved
easily in a style file are special pagestyles (like the one Leslie Lamport used in his book), numbering
conventions (e.g., equations within theorems . . . ), and special heading layouts (e.g., centered headingsor \chapter without the word "Chapter").
A very important issue is the support of national languages. Standard UTfi does not offer anything
in this regard. However, this is easily implemented as a style option as the file german.sty shows.
This file constitutes the German standard to which all German language sites agreed in 1987. See [12]for a description of its features.
Certain demands arise in business applications; for example, the need to stamp every page of the
document with date, time, name of the input file, and possibly security information.

Features Implementable with Moderate Effort
As an example of this second group, take the new implementation of the array and tabular environments described in [5, 61. In addition to the possibility of creating beautiful ruled tables, this new
implementation allows the user to specify the layout of a column in one place.
Or consider the challenge posed by David F. Rogers in [15]. He asked for a figure placement macrothat would fulfill at least three of five requirements, and states that "UTEX'S floating insert commands
also do not work". This is only partly true. Two requirements are automatically fulfilled in standard
UTEX; the remaining one (numbered figures must be inserted after the first reference to the figure) canbe easily implemented by changing only one line of code in o n e internal macro of the BTEX output
routine: in the macro \Qaddtocurcol, the call to \Oaddtotoporbot has to be changed to a call to\Oaddtobot. Of course, a style option which implements this change has to take care of the float
parameters too, since their default settings tend to discourage bottom floats.
As another example take a two-column layout where all footnotes appear at the bottom of theright column. Again this can be solved by re-defining only the internal macro \Qmakecol.
4.2

Support for Postscript printing devices"We have to acknowledge the importance of the de facto standard, POSTSCRIPT. [. . .] We must beaware of the way in which Postscript compatibility is crucial if we are to be taken seriously by the restof the world" [2, p. 1531. The question of converting the .DVI file contents to Postscript has alreadybeen taken care of, but here we are concerned with the problem of incorporating Postscript fonts. It
is easy to change lfonts. tex to use the fonts built into Postscript printers instead of the ones by
Knuth. However, this must be done at dump time, and is therefore not selectable by the user. Instead,one needs a font selection scheme that allows dynamic switching of fonts during a T@run, as outlined
in [lo].

Hard Problems
Now that we have seen that complex page make-up can be handled easily in UT$, one might wonder
which demands (in our opinion) belong to the third group. Well, page make-up for example; really
4.3

TUGboat, Volume 10 (1989), No. 4 - 1989 Conference Proceedings

complex demands such as the layout used by Scientific American: three columns, figures spanning one
to three columns with captions placed in the neighbouring column if necessary. As already mentioned,
W ' s \ i n s e r t primitive cannot be used for such a task. Doing everything by hand is possible
is a Turing engine, as Leslie Lamport remarked) but there are limitations in space and time.6
As we have already noted, we think that balancing of columns belongs to the third group if footnotes
are involved, despite the fact that the r n b o o k [3, p. 4171 implicitly says that this is possible. We
would be only too happy to see an algorithm which did not break under normal (i.e., unrestricted)
conditions.

(w

5.

Proposal for a New Implementation

The current UTEX version essentially consists of the following files:l p l a i n . t e x - plain 'I'EX features used by IATEX
I f ont s .t e x - font definitions
hyphen. t ex - hyphenation patterns
1 a t e x . t e x - most BTfl features or the internal macros to build
them in a style file- document style files and document style options*.sty
The first four of these files are all loaded when a format file is dumped. This means that a large
amount of w ' s internal memory is used to store the definitions contained in these files, even though
there are only very rare occasions when they are all used together. If we consider adding more andmore features to UT*, we are led to ask: which parts of IATg are essential for most document typt3s(called the "kernel") and which are only used by special applications (called "the peripheral part").
5.1 The UTEX Kernel
Before we can talk about re-writing the kernel, we have to separate it from the peripheral parts. The
following modules are considered part of the kernel:(defined in 1 p l a i n . t e x )0 Basic features kom plain
0 Font selection
Constants used by the rest of the program
0 Program control structure
0 Semi-parameter concept
0 Basic error handling routines
0 Spacing, line and page breaking
0 File handling
0 Counter management
0 Cross-referencing
Environment handling
Basic math commands
Generic list environment and their basic applications
Box making commands (including parbox and minipage)array and t a b u l a r
The interface for the theorem environment
Generic sectioning commands
The interface to generate tables of contents, lists of figures, etc.
0 Bibliography
Floats0 Footnotes

ne ow ever, we are working on this project at Mainz, hoping that we can prove that this problem belongs t o the second
group.

TUGboat, Volume 10 (1989), No. 4-

1989 Conference Proceedings

687

The output routine
Some of these parts need to be revised, others must be re-implemented completely: the list environment,
the writing to .aux files to remove the \ p r o t e c t feature (already done), the font selection code(already done), the counter mechanism (done), hierarchical references, array and tabular (done), ora conceptionally new output routine (certainly the hardest part). All the above parts should be better
modularized to obtain a higher degree of flexibility.
To provide better control by means of the styles or the extensions, a number of hooks, such as\everypar, will have to be introduced: think of \ e v e r y l i s t , \everysection, \everybegindocument,\everyenddocument, etc.
5.2 Peripheral Features
The peripheral parts should not be included in the format file. They can easily be moved to a numberof files that are loaded on demand during a UT$ run.
We consider the following parts to be peripheral:
Higher math. The only features currently available are eqnarray and array. A new implementation should provide the same features as M - W ,each of them loaded separately.
New verbatim with unlimited size of verbatim text and a command to input verbatim text
from a file (done).
Enhanced p i c t u r e environment (conceptionally done, partly implemented: epic, PICTEX)e Tabbing. Improvements should be discussed, e.g., push/pop over several tabbing environments.
Support for special draft options showing symbolic labels, index entries where they appear,
time and date stamps, etc.
Index: more exactly, the interface to an index program such as Makelndex.
As we mentioned earlier, a BT# installation is complete only if it provides B I B T S and Makelndex.
The integration of these programs, especially of Makelndex, i.e., the interfaces, should be improved.
5.3 Document Styles
A standard mark-up concept (SGML)
For a re-implementation of I4T$ one also has to reconsider the standard document styles. As describedin the introduction, there are different types of documents, e.g., books, manuals, articles, reports,
letters, proceedings, etc. These types cannot be interchanged since each has its own logical concepts:
letters do not possess chapters whereas there is no need for an opening or a signature in books. Given
one type of document (e.g., report), there are many different ways to do the formatting. The r e p o r tstyle of current UTEX is therefore only one out of many instances of the "meta" report style.
The important point here is that all report-type styles must use the same logical concepts so thata properly written UT$ document is independent of the specific style instance used. A German site(say, the University of Mainz) may decide to provide a special style (called, say, mi-mainz-report)
to format reports according to its own conventions. But a report written at Stanford can then be
typeset at Mainz using this style without changing the BTEX input file - but of course the document
will come out with different spacing, etc.
Therefore an important task of a new implementation is to reconsider the logical concepts used sofar, and then decide to drop or change some, or to add new ones. For example, currently there isn't
any difference between the prototype styles report and book. Obviously this cannot be correct. This
is of course a question being debated by the experts.

International language suppoTt
There is one point to make here: from what we have said above one must not infer that the textual
representation of headers ( e g , "Contents", "Litteratura") must be fixed by the style. In this respect
we disagree with Leslie Lamport. To the contrary: since it may well be that a site wants to typeset
documents written in different languages, but all in the same style, it is only reasonable to provide away to change header names. Actually we propose to make this a logical concept of the specific meta
style. This means that there must exist commands such as \chaptername and \refname that can bechanged by the document (using \renewcommand) or by style options. It is perfectly allowed (though
688

TUGboat, Volume 10 (1989), No. 4 - 1989 Conference Proceedingsnot necessarily reasonable) for a specific style to ignore these commands, and to typeset all headers inthe same way.

6.

Institutional Considerations

Leslie Lamport has copyrighted UTEX and fixed the status quo. While this is the best way to ensure
uniformity over a large group of installations and users, one runs the risk that further developments
and enhancements will become incompatible. Therefore our proposal for a new implementation isbound to fail if it becomes only one more among many others (with only a new name). We feel thatsuch a project should only be undertaken if it is supported by an institution which can channel future
developments.
6.1 Maintenance
From the size of the UT$ source code, it is clear that it must be maintained. This not only meansthat there must exist a person who will correct any bugs found; this is only part of the story, and notnecessarily the most important one. Another necessary task is to develop the software as new demands
arise. Software design is a difficult job. It is even more difficult to revise design decisions made earlier,because in addition to software development aspects, one has to consider questions of compatibility.
For the maintainance of a package the size of UTEX, one needs a group of people who can respond to
demands and wishes, and decide what can and should be done. This means that this group must include
document style as well as UTEX specialists. These people need not necessarily be the implementors
themselves. They have to set the standards, not write the macros. Nevertheless, they need to be
sufficiently familiar with U T S .

Suggestion for a UTfi Standardization Group
Certainly this is only possible if Leslie Lamport is willing to share control over UTEX. Another important point is to guarantee that this group continues to perform its task even if the individual memberschange. The logical point to organize this would be the TFJ Users Group. We think that TUG should
form a committee to discuss these problems.
6.2

7.

UpdateDuring and after the conference at Stanford, discussions were held with Leslie Lamport concerning
the issues raised in this paper. From these it became clear that he originally expected BT$ to besuperceded by some other document preparation system within a few years of its appearance. This
has not happened and now he too sees a need for its further development.
He is in agreement with the principles contained in this paper concerning the future of UT$ but
does not wish to be directly involved in their implementation. During the discussions the following
two-stage development plan was suggested:
1. Re-design the style file interface and document it: this would involve the publication of amanual on the design of style files. The resulting UTEX version would be 2.10. This version
may contain some minor enhancements visible to the user, but every input file that uses only
features documented in the current UTEX manual would work with version 2.10.
2. Produce a completely new implementation of UT$, version 3.0, according to the principles
outlined in this paper. This would be upwardly compatible in the sense that it would be possible
to process any existing document with the addition of a style option.
The timetable for this work cannot be fixed at present since it is not yet clear how much of our time
we shall be able to spend on this project, nor what support will be forthcoming &om various parties.

Bibliography[l]Bartlett, Frederick H. "Automatic Page Balancing Macros Wanted." TUGboat 9(1):83, 1988.

[2] Clark, Malcolm. "International Standards and TFJ."TUGboat 10(2):153-156, 1989.
[3] Knuth, Donald E. The W b o o k . Computers and Typesetting Vol. A. Reading, Massachusetts:
Addison-Wesley, 1986.
TUGboat, Volume 10 (1989), No. 4- 1989 Conference Proceedings689

[4] Lamport, Leslie. U T g : A Document Preparation System. User's Guide and Reference Manual.
Reading, Massachusetts: Addison-Wesley, 1985.
[5] Mittelbach, Frank. "A new implementation of the array- and tabular-environments." TUGboat
9(3):298-314, 1988.

.

[6] Mittelbach, Frank. "A new implementation of the array- and tabular-environments - addenda."
TUGboat 10(1):103-104, 1989.
[7] Mittelbach, Frank. "The doc option." TUGboat 10(2):245-273, 1989.
[8] Mittelbach, Frank. "An Extension of the U T g theorem environment." TUGboat, 1989 [forthcoming].
[9] Mittelbach, Frank. "An environment for multi-column output." TUGboat, 1989 [forthcoming].
[lo] Mittelbach, Frank, and Rainer Schopf. "A new font selection scheme for T)$
the basic macros." TUGboat 10(2):222-238, 1989.

macro packages -[ll] Mittelbach, Frank, and Rainer Schopf. "A new font selection scheme for TEX macro packages -the UTEX interface." TUGboat, [forthcoming].
[12] Partl, Hubert. "German T@." TUGboat 9(1):70-72, 1988.
[13] Podar, Sunil. Enhancements to the Picture Environment of UTEX. Dept, of Computer Science,
S.U.N.Y. at Stony Brook,Technical Report 86-17, version 1.2, July 14, 1986.
[14] Price, Lynne A. "SGML andw."TUGboat 8(2):221-225, 1987.

[15] Rogers, David F. "A Page Make-up Challenge." TUGboat 9(3):292-293, 1988.
[16] Schopf, Rainer. "Drawing histogram bars inside the IATg picture environment." TUGboat
10(1):105-107, 1989.
[17] Wonneberger, Reinhard. "Stream lists and related list types for UTEX." TUGboat 6(3):156-157,
1985.
[18] Wonneberger, Reinhard. "Chapter Mottos and Optional Semi-parameters in General and for
UTEX." TUGboat 7(3):177-185, 1986.
[19] Zalmstra, Joost, and David F. Rogers, "A Page Make-up Macro." TUGboat 10(1):73-81, 1989.

TUGboat, Volume 10 (1989), No. 4- 1989 Conference Proceedings