Modifying LATEX© Copyright 1995, LATEX Project Team.
All rights reserved.∗
12 December 1995

Contents
Introduction

1The system

2Some examples

3

Some assurances

5

Configuration possibilities

5Modification conditions

6

What do you think?

7Abstract

This document was produced in response to suggestions that the modification and distribution conditions for the files constituting the New
Standard LATEX system should be similar to those implied by Version 2of the GNU General Public Licence, as published by the Free Software
Foundation.

Introduction
This article describes the principles underlying our policy on distribution andmodification of the files comprising the LATEX system. It has been produced asa result of detailed discussions of the issues involved in the support and maintenance of a widely distributed document processing system used by diverse
people for many applications. These discussions have involved users, maintainers of installations that support LATEX and various types of organisations that
∗ This file may be distributed and/or modified under the conditions of the L
AT X Project

EPublic License, either version 1.3c of this license or (at your option) any later version. See
the source textttmodguide.tex for full details.

1distribute it. The discussions are continuing and we hope that the ideas in thisarticle will make a useful contribution to the debate.
Our aim is that LATEX should be a system which can be trusted by users of all
types to fulfill their needs. Such a system must be stable and well-maintained.
This implies that it must be reasonably easy to maintain (otherwise it will simply
not get maintained at all). So here is a summary of our basic philosophy:
We believe that the freedom to rely on a widely-used standard for
document interchange and formatting is as important as the freedom
to experiment with the contents of files.
We are therefore adopting a policy similar to that which Donald
Knuth applies to modifications of the underlying TEX system: thatcertain files, together with their names, are part of the system andtherefore the contents of these files should not be changed unless thefollowing conditions are met:
• they are clearly marked as being no longer part of the standard
system;• the name of the file is changed.

The system
In developing this philosophy, and the consequent limitations on how modifications of the system should be carried out, we were heavily influenced by thefollowing facts concerning the current widespread and wide-ranging uses of theLATEX system.
1. LATEX is not just a document processing system; it also defines a languagefor document exchange.
2. The standard document class files, and some other files, also define aparticular formatting of a document.
3. The packages that we maintain define a particular document interface and,in some cases, particular formatting of parts of a document.
4. The interfaces between different parts of the LATEX system are very complex and it is therefore very difficult to check that a change to one filedoes not affect the functionality of both that file and also other parts ofthe system not obviously connected to the file that has been changed.
This leads us to the general principle that:with certain special exceptions, if you change the contents of a filethen the changed version should have a different file name.

2

We certainly do not wish to prevent people from experimenting with the code indifferent ways and adapting it to their purposes. However, we are concerned thatany distribution of modifications to the code should be very clearly identified as
not being a part of the standard distribution. The exact wording and form of
the distribution conditions is thus something that is flexible, but only within theconstraint of keeping LATEX as a standardised, reliable product for the purposes
described above: the exchange and formatting of documents.

Some examples
Here we elaborate the arguments that have led us to the above conclusion.
Separate development considered harmful!
In many fields, the use of LATEX as a language for communication is just as important as its capacity for fine typesetting; this is a very important consideration
for a large population of authors, journal editors, archivists, etc.
Related to this issue of portability is the fact that the file names are part of theend-user syntax.
As a real example, the LATEX ‘tools’ collection contains the package ‘array.sty’.
A new user-level feature was added to this file at the end of 1994 and a document
using this feature can contain the line:\usepackage{array}[1994/10/16]

By supplying the optional argument, the document author is indicating that aversion of the file array.sty dated no earlier than that date is required to run
this document without error.
This feature would be totally worthless if we were to allow an alternative versionof the array package to be distributed under the same name since it would meanthat there would be in circulation files of a later date, but without the newfeature. If the document were processed using this ‘alternative array’ then it
would certainly produce ‘undefined command’ errors and would probably not
be processable at all.
What’s in a file-name?
In a pure markup language, such as SGML, it is reasonably clear that control
over the final presentation lies with the receiver of a document and not with theauthor.
However, the way that LATEX is often used in practice means that most people(at least when using the standard classes and packages) expect the formatting
to be preserved when they send the document to another site.
For example, suppose, as is still the most common use of LATEX in publishing,
you produce a document for ‘camera-ready-copy’ using the class ‘article’ and3that you carefully tune the formatting by, for example, adding some explicit
line breaks etc, to ensure that it fits the 8 page limit set by the editor a journal
or proceedings.
It then gets sent to the editor or a referee who, without anyone knowing, has a
non-standard version of the class file ‘article’ and so it then runs to 9 pages. The
consequence of this will, at the least, be a lot of wasted time whilst everyone
involved works out what has gone wrong; it will probably also lead to everyone
blaming each other for something which was in fact caused by a misguided
distribution policy.
It should also be noted that, for most people, the version of the class file ‘article’that gets used is decided by a site maintainer or the compilers of a CD-ROM
distribution. To most users, the symbols a r t i c l e in:\documentclass{article}

are just as much part of LATEX’s syntax as are the symbols 1 2 p t in:\hspace{12pt}

Thus they should both define a standard formatting rather than sometimes
producing 1 more page or a 5pt larger space.
Users rely on the fact that the command (or menu item) ‘LaTeX’ produces acompletely standard LATEX, including the fact that ‘article’ is the ‘standard article’. They would not be at all happy if the person who installed and maintains
LATEX for them were allowed to customise ‘article’ every second day so as (inher or his opinion) to improve the layout; or because another user wanted towrite a document in a different language or typeset one with different fonts.
TEX itself
We have modelled our policies on those of the TEX system since this has forsome time now been widely acknowledged as a very stable and high quality
typesetting system.
The distribution policy set up by Donald Knuth for TEX has the followingfeatures:• There is a clearly specified method for changing parts of the software by
the use of ‘change files’.
• Although arbitrary changes are allowed, the resulting program can becalled TEX only if its functionality is precisely the same as that of TEX(i.e. neither less nor more) in all important areas.
• There are many files in the system that cannot be changed at all (without changing the name): examples are the file plain.tex and the files
associated with fonts, including the Metafont source files.

4Maintaining complexity
Our experience of maintaining LATEX has shown us just how complex are theinteractions between different parts of the system.
We have therefore, with lots of help from the bug reports you send in, developeda large suite of test files which we run to check the effects of every change wemake. A non-negligible percentage of these test runs give unexpected results
and hence show up some unexpected dependency in the system.

Some assurances
We are certainly not attempting to stop people reformatting LATEX documents inany way they wish. There are many ways of customising incoming documents
to your personal style that do not involve changing the contents of LATEX’s
standard files; indeed, this freedom is one of the system’s many advantages.
The simplest way to achieve this is to replace\documentclass{article} by\documentclass{myart}

Nor do we wish to discourage the production of new packages improving on thefunctionality or implementation of those we distribute. All we ask is that, inthe best interests of all LATEX users, you give your superbly improved class or
package file some other name.

Configuration possibilities
The standard LATEX system format can be configured in several ways to suit theneeds and resources of an installation. For example, the loading of fonts andfont tables can be customised to match the font shapes, families and encodings
normally used in text mode. Also, by producing the appropriate font definition
files, the font tables themselves can be set up to take advantage of the available
fonts and sizes. The loading of hyphenation patterns can be adjusted to cover
the languages used; this has to be done as part of making the format since thisis the only stage at which patterns can be loaded.
A complete list of these configuration possibilities can be found in the distributed
guide Configuration options for LATEX 2ε (cfgguide.tex). However, as it says
there, the number of configuration possibilities is strictly limited; we hope thathaving read this far you will appreciate the reasons for this decision. One consequence of this is that there is no provision for a general purpose configuration
file, or for adding extra code just before the \dump of the format file.
This was a deliberate decision and we hope that everyone (yes, that includesyou!) will support its intent. Otherwise there will be a rapid return to thevery situation, of several incompatible versions of LATEX 2.09, that originallyprompted us to produce LATEX 2ε : the new, and only, ‘Standard LATEX’. This
will make LATEX unmaintainable and, hence, unmaintained (by us, at least).
5

Therefore you should not misuse the configuration files or other partsof the distribution to produce non-standard versions of LATEX.
Some of the allowed configurations can result in a system that can produce
documents that are no longer ‘formatting compatible’; for example, the use ofdifferent default fonts will most likely produce different line and page breaks.
If you do produce a system that is configured in such a way that it is not‘formatting compatible’ then you should consider carefully the needs of users
who need to create portable documents. A good way to provide for their needs isto make available, in addition, a standard form of LATEX without any ‘formatting
incompatible’ customisations.

Modification conditions
It is possible that you need to produce a document processing system based onstandard LATEX but with functionality that cannot be implemented by using theapproved configuration files and complying with the restriction on the code thatis allowed in them. In other words, you may need a system which is sufficiently
distinct from Standard LATEX that it is not feasible to do this simply by using
the configuration options we provide or by producing new classes and packages.
If you do produce such a system then, for the reasons described above, youshould ensure that your system is clearly distinguished from Standard LATEX inevery possible way, including the following.
1. Give your system a distinguished name, such as NS-TeX, which clearly
distinguishes it from LATEX.
2. Ensure that it contains no file with a name the same as that of a file in thestandard distribution but with different contents. (If this is not possible
then you must:• ensure that files from the non-LATEX system cannot be accidentally
accessed whilst using a standard LATEX;• ensure that each file from the non-LATEX system clearly identifies
itself as a non-LATEX file on the terminal and in the log file.)
3. Ensure that the method used to run your system is clearly distinct fromthat used to run Standard LATEX; e.g. by using a command name or menu
entry that is clearly not latex (or LaTeX etc).
4. Ensure that, when a file is being processed by your system, the use ofnon-standard LATEX is clearly proclaimed to the user by whatever means
is appropriate.
5. Ensure that what is written at the beginning of the log file clearly showsthat your system has been used, and that it is not Standard LATEX. See
the file cfgguide.tex for how to achieve this.
6. Clearly explain to users that bug reports concerning your system should
not be sent to the maintainers of Standard LATEX.
6Note to system administrators
If you install a non-standard (modified) version of LATEX on a multi-user sitethen please, in addition, install Standard LATEX and observe the conditions
enumerated above, particularly 3.

What do you think?
We are interested in your views on the issues raised in this document. The best
way to let us know what you think, and to discuss your ideas with others, is tojoin the LaTeX-L mailing list and send your comments there. To subscribe tothis list, mail to:listserv@urz.uni-heidelberg.de

the following one line message:
subscribe LATEX-L ⟨your-first-name⟩ ⟨your-second-name⟩7