Structures to be supported

David Rhead

April 1992

Contents

1 Motivation 1 1.1 Dual role of 2.09 style files . . . . . . . . . . . . . . . . . . . . 1 1.2 Practical difficulties at 2.09 . . . . . . . . . . . . . . . . . . . 2 1.3 Suggestion for 3.0 . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Structures to be supported 3 2.1 First proposition . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2 Second proposition . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3 Notes about AAP analysis . . . . . . . . . . . . . . . . . . . . 4

2.3.1 Three basic structures . . . . . . . . . . . . . . . . . . 4 2.3.2 Borderline cases . . . . . . . . . . . . . . . . . . . . . 5 2.3.3 Advantages of AAP analysis . . . . . . . . . . . . . . 5 2.3.4 Disadvantages of AAP analysis . . . . . . . . . . . . . 6 2.3.5 Attitude to AAP analysis . . . . . . . . . . . . . . . . 6

2.4 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.5 Bonuses from using structures influenced by Chicago/AAP . 8

2.5.1 Conference proceedings . . . . . . . . . . . . . . . . . 8 2.5.2 Page selection . . . . . . . . . . . . . . . . . . . . . . . 8 2.5.3 Generally . . . . . . . . . . . . . . . . . . . . . . . . . 9

3 Modularity 9 3.1 Analysis in general . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2 Structure supported by mapping software . . . . . . . . . . . 10

References 10

1 Motivation

1.1 Dual role of 2.09 style files

In L^{A}TEX 2.09, “style files” confuse 2 roles:

• definition of a structure. (I think I’ve heard this given as a justification for the designs: “the designs don’t matter, because the style-files are just there to define what structures are supported”.)

• mapping the structure into a design.

For example:

• article.sty and xarticle.sty seem to map the same structure (the “L^{A}TEX 2.09 analysis of the structure of an article”) into different designs

• the command \documentstyle{siam} seems to map “siam’s analysis of the structure of an article” into “siam’s design for an article”. (If so, then the roles of \documentstyle[11pt]{siam} and \documentstyle[12pt]{siam} are unclear. Are they intended as “preprint styles”, for an author to use while a paper is being drafted?)

   • the commands \documentstyle[onecolumn,10pt]{iso} and
     \documentstyle[twocolumn,9pt]{iso} seem to map “the structure

of an ISO standard” into “two designs for ISO standards”.

Changing from \documentstyle{article} to \documentstyle{xarticle}

will work (i.e., give a document with the same structure but a different design), but changing from \documentstyle{article} to

\documentstyle{siam} or to \documentstyle{iso} won’t work.

The analysis that was done for version 2.09 is mostly implicit in sty files, rather than being available explicitly. Subsequent providers of sty files have generally followed the same practice (although some provide supplementary documentation). Thus, a user who just wants his/her current structure laid out in a different design may end up reading lots of archived sty file code to see whether an alternative sty file supports the structure they are currently using.

1.2 Practical difficulties at 2.09

Someone attempting to produce a book/thesis with L^{A}TEX 2.09 has to change various defaults:

• they will want their preliminary pages numbered in roman, but will want to switch back to arabic at the start of their main text. They may need a \setcounter to start the roman sequence at the right place.

• they will probably want units such as “acknowledgements” and “references” to appear in their “table of contents”. They will be using \chapter* for such units (to get headings that look appropriate), so will have to use \addcontentsline to get the units mentioned in the “table of contents”.

• page-selection can be a problem, since \count0 doesn’t distinguish between roman and arabic.

People producing “an issue of a journal”, or a conference-proceedings, may have additional problems:

• if they treat the work as book [1, p. 23], they will be faced with trying to get authors’ names, affiliations, etc., typeset consistently at the start of each chapter.

• if they leave the work as a series of articles, they will be faced with ensuring that numbering (of pages, etc.) follows on.

I think that these problems arise because the analysis of “document structure” for the L^{A}TEX 2.09 “standard styles” is inappropriate:

• the concepts of “front matter” and “back matter” are well known in publications about book design, etc., but aren’t supported by the 2.09 “standard styles”

• an “issue of a journal”, and a conference-proceedings, have structures of their own (which are different from the structure of an ordinary book).

1.3 Suggestion for 3.0

I think that there would be advantages in:

1. keeping a clear distinction between “the structure supported” and “the design into which the structure is mapped”, so that the end-user will known when they can/cannot change design by changing just one line of their tex file.

2. associated with (1), thinking in terms of “software that maps a structure into a design”, rather than “style file” which confuses “structure supported” with “design into which the structure is mapped”

3. analyzing in more depth the structure of the types of documents to be supported. Then, for example, the end-user will be able to just say “this is front matter”, and so have details such as roman/arabic numbering, heading style, and “table of contents” entries taken care of automatically in accordance with the relevant design (or house-style).

2 Structures to be supported

Various gurus [2, 3, 4, 5, 6, 7, 8] give analyses of the structures of the document-classes for which people use L^{A}TEX 2.09. Although, there may be differences between the analyses offered by different gurus, I think that it would be better for the project to consult the gurus, rather than to ignore them (since otherwise the project will waste time re-doing the work already done by the gurus).

2.1 First proposition

It is easier to select the “good bits” from off-the-shelf analyses than to start from nothing.

2.2 Second proposition

For overall structure, particularly “good bits” are to be found in the Chicago Manual of Style [2, pages 4,5] and in the SGML DTDs published by the Association of American Publishers [3, appendix B].

2.3 Notes about AAP analysis

2.3.1 Three basic structures

Broadly, the AAP analysis defines three basic structures:

BK-1 book/monograph/textbook, conference proceedings, technical report, thesis/dissertation

ART-1 article, feature

SER-1 serial,^{1} conference-proceedings. (Articles are embedded within a serial without any modifications.)

Thus, although the L^{A}TEX 2.09 and AAP analyses both define 3 main structures, the boundaries are drawn differently:

• the AAP regards reports and books as having the same basic BK-1 structure (unlike L^{A}TEX 2.09, which has two distinct “standard styles”, report and book, the main difference being that book isn’t allowed to have an abstract)

• whereas the L^{A}TEX 2.09 manual suggests [1, p. 23] that “it is easy to include an article as a chapter in a report or book”, the AAP defines a special structure, SER-1, for multi-author works made up of separate articles.

2.3.2 Borderline cases

Some types of document may lie on the borderline between two AAP categories. For example, a long report might be divided into units called chapters and be appropriately classified as BK-1, while a short report might be divided into units called sections and be more akin to ART-1. (Compare [3], which envisages that technical reports will have BK-1 structure, with [7] which envisages that technical reports will be divided into sections.)

At worst, cases that cross borderlines might need two mappings. In the report example, they might be (1) a mapping of BK-1 structure to a report design, and (2) a mapping of ART-1 structure to a report design. (This is no worse than the situation with the L^{A}TEX 2.09 “standard styles”, which also envisage that report is made up of chapters.) Thus, adoption of AAP classification would not cause insuperable difficulties.

1I think they mean “an issue of a serial”. See section 2.3.4.

2.3.3 Advantages of AAP analysis

Paying serious attention to the AAP analysis would have various advantages:

• the analysis is well-known

• it covers the types of documents that current L^{A}TEX-users generally want to produce

• it generally (but not always) gives analysis to the depth that L^{A}TEX 3.0 might need

• other gurus cite it (if only to disagree with it)

• it embodies knowledge about publishing practice that the average L^{A}TEX-er doesn’t have

• it is finite. The project would not be attempting to analyse all possible documents, but would be concentrating on the structures that are most commonly required.

• support for AAP-like structures might attract “real publishers” to L^{A}TEX

• it exists now (unlike, for example, the European journal-publishers’ work [4], which is still in progress).

2.3.4 Disadvantages of AAP analysis

The AAP analysis is not suitable in all respects as a model of what L^{A}TEX 3.0 (and associated software) should do:

• The analysis may go deeper in some areas than is required for L^{A}TEX 3.0. (If something with the “look and feel” of SGML is required, one might as well use SGML.)

• On the other hand, the analysis doesn’t go deep enough in other areas. For example, the AAP analysis is no better than the L^{A}TEX 2.09 analysis for:

– citations and reference-lists [10];

– captions, legends and credit-lines [2, ch. 11];

– notes to tables [2, ch. 12].

Other gurus’ analyses would have to be used in such areas.

• At a recent SGML meeting [9], the AAP standard was described as too Anglo-centric. Hence the European journal-publishers’ work [4] was criticised as too AAP-influenced.

• “Serial” is usually used (e.g., by librarians) to describe a publication that could potentially continue indefinitely (e.g., all the issues of a journal, including those not yet published). Therefore SER-1 may be a poor choice of name for a structure that would represent “a single issue of a series” or a “one-off conference proceeedings”. MULTI-1 might have been a better name for such multi-author (or multi-article) works.

2.3.5 Attitude to AAP analysis

An analysis based on that given by the AAP (minus a few details, plus a few other details which could be taken from [2] and other places) might give a reasonable compromise between:

• “re-inventing the wheel”

• blindly obeying something (AAP structure) that hasn’t been thought through in all respects.

2.4 Example

For example, if some compromise was made between the Chicago analysis and the AAP analysis, one might envisage a user preparing a file of the form:

.
\begin{frontmatter}
\frontelement{Foreword}
...
\frontelement{Preface}
...
\frontelement{Acknowledgements}
...
\frontelement{Dedication}
...
\frontelement{Abstract}

   ...
\end{frontmatter}
\begin{bodymatter}
   \chapter{...}
   ...
\end{bodymatter}
\begin{appendices}
   \appendix{...}
   ...
\end{appendices}
\begin{backmatter}  %  short for "other back matter"
   \backelement{Glossary}
   ...
   \backelement{Notes}
   ...
\end{backmatter}

Note

The above example assumes that, for L^{A}TEX purposes:

• it will generally be sufficient to think in terms of “front matter elements” and “back matter elements”

• it will not be appropriate to go for complete analogy with the AAP’s SGML DTD. Thus, one would not expect typical L^{A}TEX 3.0 software to define environments like \acknowledgements: if L^{A}TEX 3,0 gets used as a back-end for an SGML system, the AAP’s <ack> would get

     converted to \frontelement{Acknowledgements}. (However, if any

elements required special treatment, particular environments could be defined for them, as is done in L^{A}TEX 2.09 with abstract.)

2.5 Bonuses from using structures influenced by Chicago/AAP

2.5.1 Conference proceedings

A document with structure based on SER-1 will naturally support “a reference-list at the end of each chapter” plus the option of a composite bibliography at the end of the document (for which one sometimes sees in requests in electronic digests from editors of conference proceedings).

Because the structure is appropriate, there should be less conflict than if one is (for example) mis-using the 2.09 book structure. One shouldn’t end up trying to have thebibliography at both 2.09 “section” level and at “chapter” level, because the “references at end of article” and “bibliography at end of complete work” units would have different definitions. For BibTEX, one could envisage a scheme involving perhaps article1.bbl, …

, articleN.bbl, backmatter.bbl.

2.5.2 Page selection

Such an analysis would lead naturally to schemes for using the \counts sensibly, so as to support:

• distinction between roman and arabic numbered pages (i.e., front matter and main text)

• selection of “all the front matter”, a whole chapter, a whole appendix, or “all the (non-appendix) back matter”.

For example, one might have:

Major division Minor divisions \count0       \count1           \count2
Front matter  page-number -1                0
Main text  chapters  page-number chapter-number  0

                                                1, 2, ...

Back matter:  appendices  page-number appendix number 1
appendices  1, 2, ...
Back matter: glossary page-number -2 0
other units  bibliography

index, etc.

2.5.3 Generally

Generally, if a correct analysis of structure is made, practical details will tend to fall into place nicely, rather than needing messy ad hoc circumventions.

3 Modularity

3.1 Analysis in general

Although I’ve suggested that a Chicago/AAP analysis might provide a suitable basis for “structures to be supported by L^{A}TEX 3.0”:

• any “L^{A}TEX 3.0 project” selection of “the good bits” is unlikely to be perfect

• some better analysis may come along, and some successor to the “L^{A}TEX 3.0 project” may want to support that analysis rather than one derived from the suggestions given here

• people may have to produce “structure to design” mappings for structures other than the 3 “modified AAP” ones (e.g., legal articles, ISO standards, SGML DTDs other than the 3 AAP ones)

• people may produce “structure to design” mappings for enhancements of the 3 “modified AAP” ones (e.g., a book that contains plates and maps, if they are to be numbered separately from other illustrations).

It seems desirable that such possibilities should be borne in mind when any software is being written.

3.2 Structure supported by mapping software

I think that mapping software (i.e., whatever we call the successors to 2.09 “style files”) should make clear the structure that is supported, for example:

• by software checks

• because the mapping software starts with a comment that defines the structure it supports.

Then end-users will know (or find out in a friendly way) whether or not they can simply “change design by changing one line of the tex file”.

For example:

• a thesis and a Wiley book might have the same structure, so a oneline change to the tex file should lead to a change from one design to another (with no change to the structure)

• papers in different physics journals will probably have the same structure, so a one-line change to the tex file should lead to a change from one journal’s design to another’s

• ISO standards have their own structure. Someone who tries to apply typesetting software that is intended for a different structure (e.g., an AAP-based structure) should get a sensible error message.

References

[1] Leslie Lamport. LaTeX: a document preparation system. Addison-Wesley, 1986.

[2] Chicago manual of style. 13th edition. Chicago: University of Chicago Press, 1982.

[3] Electronic manuscript preparation and markup: ANSI/NISO Z39.59-1988. New Brunswick: Transaction publishers, 1991. ISBN 0-88738-945-7.

[4] DTD for article headers. Amsterdam: European workgroup on SGML, 1991.

[5] Jan V. White. Graphic design for the electronic age. Watson-Guptill, 1988.

[6] Presentation of theses and dissertations. BS 4821. British Standards Institution, 1990.

[7] Presentation of research and development reports. BS 4811. British Standards Institution, 1972.

[8] C. M. Sperberg-McQueen and Lou Burnard. Guidelines for the encoding and interchange of machine-readable texts. Draft version 1.1. Oxford, Chicago: Text Encoding Initiative, 1990.

[9] Michael Popham. Report on inaugural meeting of UK chapter of SGML Users’ Group. Report number 8, SGML project, Exeter University, 1992.

[10] Documentation — bibliographic references — content, form and structure. ISO 690. International Organization for Standardization, 1987.