% \iffalse meta-comment
%
% Copyright 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006
% The LaTeX3 Project and any individual authors listed elsewhere
% in this file.
%
% This file is part of the LaTeX base system.
% -------------------------------------------
%
% It may be distributed and/or modified under the
% conditions of the LaTeX Project Public License, either version 1.3c
% of this license or (at your option) any later version.
% The latest version of this license is in
% http://www.latex-project.org/lppl.txt
% and version 1.3c or later is part of all distributions of LaTeX
% version 2005/12/01 or later.
%
% This file has the LPPL maintenance status "maintained".
%
% The list of all files belonging to the LaTeX base distribution is
% given in the file `manifest.txt'. See also `legal.txt' for additional
% information.
%
% The list of derived (unpacked) files belonging to the distribution
% and covered by LPPL is defined by the unpacking scripts (with
% extension .ins) which are part of the distribution.
%
% \fi
% Filename: clsguide.tex
\NeedsTeXFormat{LaTeX2e}[1995/12/01]
\documentclass{ltxguide}[1995/11/28]
\title{\LaTeXe~for class and package writers}
\author{Copyright \copyright~1995--2006 The \LaTeX3 Project\\
All rights reserved}
\date{15 February 2006}
\begin{document}
\maketitle
\tableofcontents
\section{Introduction}
This document is an introduction to writing classes and packages for
\LaTeX{}, with special attention given to upgrading existing
\LaTeX~2.09 packages to \LaTeXe{}. The latter subject is also
covered in an article by Johannes Braams published in TUGboat~15.3.
\subsection{Writing classes and packages for \LaTeXe}
\LaTeX{} is a document preparation system that enables the document
writer to concentrate on the contents of their text, without bothering
too much about the formatting of it. For example, chapters are
indicated by |\chapter{
}| rather than by selecting 18pt bold.
The file that contains the information about how to turn logical
structure (like `|\chapter|') into formatting (like `18pt bold ragged
right') is a \emph{document class}. In addition, some features (such
as colour or included graphics) are independent of the document class
and these are contained in \emph{packages}.
One of the largest differences between \LaTeX~2.09 and \LaTeXe{} is in
the commands used to write packages and classes. In \LaTeX~2.09,
there was very little support for writing |.sty| files, and so writers
had to resort to using low-level commands.
\LaTeXe{} provides high-level commands for structuring packages.
It is also much easier to build classes and packages on top of each
other, for example writing a local technical report class |cetechr|
(for the Chemical Engineering department) based on |article|.
\subsection{Overview}
This document contains an overview of how to write classes and
packages for \LaTeX{}. It does \emph{not} introduce all of the
commands necessary to write packages: these can be found in either
\emph{\LaTeXbook} or \emph{\LaTeXcomp}. But it does describe the new
commands for structuring classes and packages.
\begin{description}
\item[Section~\ref{Sec:general}] contains some general advice about
writing classes and packages. It describes the difference between
classes and packages, the command naming conventions, the use of
|doc| and |docstrip|, how \TeX's primitive file and box commands
interact with \LaTeX{}. It also contains some hints about general
\LaTeX{} style.
\item[Section~\ref{Sec:structure}] describes the structure of classes
and packages. This includes building classes and packages on top of
other classes and packages, declaring options and declaring
commands. It also contains example classes.
\item[Section~\ref{Sec:commands}] lists the new class and package
commands.
\item[Section~\ref{Sec:upgrade}] gives detailed advice on how to
upgrade existing \LaTeX~2.09 classes and packages to \LaTeXe{}.
\end{description}
\subsection{Further information}
For a general introduction to \LaTeX{}, including the new features of
\LaTeXe{}, you should read \emph{\LaTeXbook}
by Leslie Lamport~\cite{A-W:LLa94}.
A more detailed description of the new features of \LaTeX, including an
overview of more than 200 packages and nearly 1000 ready to run examples, is
to be found in \emph{\LaTeXcomp second edition} by Frank Mittelbach and
Michel Goossens~\cite{A-W:MG2004}.
The \LaTeX{} system is based on \TeX{}, which is
described in \emph{The \TeX book} by Donald E.~Knuth~\cite{A-W:DEK91}.
There are a number of documentation files which accompany every copy
of \LaTeX{}. A copy of \emph{\LaTeX{} News} will come out with each
six-monthly release of \LaTeX{}, and is found in the files
|ltnews*.tex|. The author's guide \emph{\usrguide} describes the new
\LaTeX{} document features; it is in |usrguide.tex|. The guide
\emph{\fntguide} describes the \LaTeX{} font selection scheme for
class- and package-writers; it is in |fntguide.tex|. Configuring
\LaTeX{} is covered by the guide \emph{\cfgguide} in
\texttt{cfgguide.tex} whilst the philosophy behind our policy on
modifying \LaTeX{} is described in \emph{\modguide} in
\texttt{modguide.tex}.
The documented source code (from the files used to produce the kernel
format via |latex.ltx|) is now available as
\emph{The \LaTeXe\ Sources}.
This very large document also includes an index of
\LaTeX{} commands. It can be typeset from the \LaTeX{} file
|source2e.tex| in the |base| directory, using the source files and
the class file |ltxdoc.cls| from this directory.
For more information about \TeX{} and \LaTeX{}, please contact your
local \TeX{} Users Group, or the international \TeX{} Users Group.
Addresses and other details can be found at:
\begin{quote}\small\label{addrs}
\texttt{http://www.tug.org/lugs.html}
\end{quote}
\subsection{Policy on standard classes}
Many of the problem reports we receive concerning the standard classes
are not concerned with bugs but are suggesting, more or less politely,
that the design decisions embodied in them are `not optimal' and
asking us to modify them.
There are several reasons why we should not make such changes to these
files.
\begin{itemize}
\item
However misguided, the current behaviour is clearly what was
intended when these classes were designed.
\item
It is not good practice to change such aspects of `standard classes'
because many people will be relying on them.
\end{itemize}
We have therefore decided not to even consider making such
modifications, nor to spend time justifying that decision. This does
not mean that we do not agree that there are many deficiencies in the
design of these classes, but we have many tasks with higher priority
than continually explaining why the standard classes for \LaTeX{}
cannot be changed.
We would, of course, welcome the production of better classes, or of
packages that can be used to enhance these classes. So your first
thought when you consider such a deficiency will, we hope, be ``what
can I do to improve this?''
Similar considerations apply to those parts of the kernel that are
implementing design decisions, many of which should be left to the
class file but are not in the current system. We realise that in such
cases it is much more difficult for you to rectify the problem
yourself but it is also the case that making such changes in the
kernel would probably be a major project for us; therefore such
enhancements will have to wait for \LaTeX3.
\section{Writing classes and packages}
\label{Sec:writing}
This section covers some general points concerned with writing
\LaTeX{} classes and packages.
\subsection{Old versions}
If you are upgrading an existing \LaTeX~2.09 style file then we
recommend freezing the 2.09 version and no longer maintaining it.
Experience with the various dialects of \LaTeX{} which existed in the
early 1990's suggests that maintaining packages for different versions
of \LaTeX{} is almost impossible. It will, of course, be necessary
for some organisations to maintain both versions in parallel for some
time but this is not essential for those packages and classes
supported by individuals: they should support only the new standard
\LaTeXe{}, not obsolete versions of \LaTeX{}.
\subsection{Using `docstrip' and `doc'}
If you are going to write a large class or package for \LaTeX{} then
you should consider using the |doc| software which comes with
\LaTeX{}.
\LaTeX{} classes and packages written using this can be
processed in two ways: they can be run through \LaTeX{}, to produce
documentation; and they can be processed with |docstrip|, to produce
the |.cls| or |.sty| file.
The |doc| software can automatically generate indexes of definitions,
indexes of command use, and change-log lists. It is very useful for
maintaining and documenting large \TeX{} sources.
The documented sources of the \LaTeX{} kernel itself, and of the
standard classes, etc, are |doc| documents; they are in the |.dtx|
files in the distribution. You can, in fact, typeset the source code
of the kernel as one long document, complete with index, by running
\LaTeX{} on |source2e.tex|. Typesetting these documents uses the
class file |ltxdoc.cls|.
For more information on |doc| and |docstrip|, consult the files
|docstrip.dtx|, |doc.dtx|, and \emph{\LaTeXcomp}. For examples of its
use, look at the |.dtx| files.
\subsection{Is it a class or a package?}
\label{Sec:classorpkg}
The first thing to do when you want to put some new \LaTeX{} commands
in a file is to decide whether it should be a \emph{document class} or a
\emph{package}. The rule of thumb is:
\begin{quote}
If the commands could be used with any document class, then make
them a package; and if not, then make them a class.
\end{quote}
There are two major types of class: those like |article|, |report| or
|letter|, which are free-standing; and those which are extensions or
variations of other classes---for example, the |proc| document class,
which is built on the |article| document class.
Thus, a company might have a local |ownlet| class for printing letters
with their own headed note-paper. Such a class would build on top of
the existing |letter| class but it cannot be used with any other
document class, so we have |ownlet.cls| rather than |ownlet.sty|.
The |graphics| package, in contrast, provides commands for including
images into a \LaTeX{} document. Since these commands can be used
with any document class, we have |graphics.sty| rather than
|graphics.cls|.
\subsection{Command names}
\LaTeX{} has three types of command.
There are the author commands, such as |\section|, |\emph| and
|\times|: most of these have short names, all in lower case.
There are also the class and package writer commands:
most of these have long mixed-case names such as the following.
\begin{verbatim}
\InputIfFileExists \RequirePackage \PassOptionsToClass
\end{verbatim}
Finally, there are the internal commands used in the \LaTeX{}
implementation, such as |\@tempcnta|, |\@ifnextchar| and |\@eha|:
most of these commands contain |@| in their name, which means they
cannot be used in documents, only in class and package files.
Unfortunately, for historical reasons the distinction between these
commands is often blurred. For example, |\hbox| is an internal
command which should only be used in the \LaTeX{} kernel, whereas
|\m@ne| is the constant $-1$ and could have been |\MinusOne|.
However, this rule of thumb is still useful: if a command has |@| in
its name then it is not part of the supported \LaTeX{} language---and
its behaviour may change in future releases! If a command is
mixed-case, or is described in \emph{\LaTeXbook}, then you can rely on
future releases of \LaTeXe{} supporting the command.
\subsection{Box commands and colour}
\label{Sec:colour}
Even if you do not intend to use colour in your own documents, by
taking note of the points in this section you can ensure that your
class or package is compatible with the |color| package. This may
benefit people using your class or package who have access to colour
printers.
The simplest way to ensure `colour safety' is to always use \LaTeX{}
box commands rather than \TeX{} primitives, that is use |\sbox| rather
than |\setbox|, |\mbox| rather than |\hbox| and |\parbox| or
the |minipage| environment rather than |\vbox|.
The \LaTeX{} box commands have new options which mean that they are now
as powerful as the \TeX{} primitives.
As an example of what can go wrong, consider that in
|{\ttfamily }|
the font is restored just \emph{before} the |}|, whereas in the
similar looking construction
|{\color{green} }|
the colour is restored just \emph{after} the final |}|. Normally this
distinction does not matter at all; but consider a primitive \TeX{}
box assignment such as:
\begin{verbatim}
\setbox0=\hbox{\color{green} }
\end{verbatim}
Now the colour-restore occurs after the |}| and so is \emph{not}
stored in the box. Exactly what bad effects this can have depends on
how colour is implemented: it can range from getting the wrong
colours in the rest of the document, to causing errors in the
dvi-driver used to print the document.
Also of interest is the command |\normalcolor|. This is
normally just |\relax| (i.e., does nothing)
but you can use it rather like |\normalfont| to
set regions of the page such as captions or section headings to the
`main document colour'.
\subsection{Defining text and math characters}
\label{Sec:chars}
Because \LaTeXe{} supports different encodings, definitions of commands
for producing symbols, accents, composite glyphs, etc.\ must be
defined using the commands provided for this purpose and described in
\emph{\fntguide}. This part of the system is still under development
so such tasks should be undertaken with great caution.
Also, |\DeclareRobustCommand| should be used for encoding-independent
commands of this type.
Note that it is no longer possible to refer to the math font set-up
outside math mode: for example, neither |\textfont 1| nor
|\scriptfont 2| are guaranteed to be defined in other modes.
\subsection{General style}
\label{Sec:general}
The new system provides many commands designed to help you produce
well-structured class and package files that are both robust and
portable. This section outlines some ways to make intelligent use of
these.
\subsubsection{Loading other files}
\label{Sec:loading}
\NEWdescription{1995/12/01}
\LaTeX{} provides these commands:
\begin{verbatim}
\LoadClass \LoadClassWithOptions
\RequirePackage \RequirePackageWithOptions
\end{verbatim}
for using classes or packages inside other classes or packages. We
recommend strongly that you use them, rather than the primitive
|\input| command, for a number of reasons.
Files loaded with |\input | will not be listed in the
|\listfiles| list.
If a package is always loaded with |\RequirePackage...| or |\usepackage|
then, even if its loading is requested several times, it will be
loaded only once. By contrast, if it is loaded with |\input| then it
can be loaded more than once; such an extra loading may waste time and
memory and it may produce strange results.
If a package provides option-processing then, again, strange results
are possible if the package is |\input| rather than loaded by means of
|\usepackage| or |\RequirePackage...|.
If the package |foo.sty| loads the package |baz.sty| by use of
|\input baz.sty| then the user will get a warning:
\begin{verbatim}
LaTeX Warning: You have requested package `foo',
but the package provides `baz'.
\end{verbatim}
Thus, for several reasons, using |\input| to load packages is not a
good idea.
Unfortunately, if you are upgrading the file |myclass.sty| to a class
file then you have to make sure that any old files which contain
|\input myclass.sty| still work.
This was also true for the standard classes (|article|, |book| and
|report|), since a lot of existing \LaTeX~2.09 document styles contain
|\input article.sty|. The approach which we use to solve this is
to provide minimal files |article.sty|, |book.sty| and |report.sty|,
which simply load the appropriate class files.
For example, |article.sty| contains just the following lines:
\begin{verbatim}
\NeedsTeXFormat{LaTeX2e}
\@obsoletefile{article.cls}{article.sty}
\LoadClass{article}
\end{verbatim}
You may wish to do the same or, if you think that it is safe to do so,
you may decide to just remove |myclass.sty|.
\subsubsection{Make it robust}
We consider it good practice, when writing packages and classes, to use
\LaTeX{} commands as much as possible.
Thus, instead of using |\def...| we recommend using one of
|\newcommand|, |\renewcommand| or |\providecommand|; |\CheckCommand| is
also useful. Doing this makes
it less likely that you will inadvertently redefine a command, giving
unexpected results.
When you define an environment, use |\newenvironment| or
|\renewenvironment| instead |\def\foo{...}| and |\def\endfoo{...}|.
If you need to set or change the value of a \m{dimen} or \m{skip}
register, use |\setlength|.
To manipulate boxes, use \LaTeX{} commands such as |\sbox|,
|\mbox| and |\parbox| rather than |\setbox|, |\hbox| and |\vbox|.
Use |\PackageError|, |\PackageWarning| or |\PackageInfo| (or the
equivalent class commands) rather than |\@latexerr|, |\@warning| or
|\wlog|.
It is still possible to declare options by defining |\ds@