path: root/Master/texmf-dist/doc/latex/relenc/relenc.tex

\documentclass[a4paper]{article}

\usepackage{doc}
% Stuff more or less from ltxdoc.cls:
\DeclareFontShape{OT1}{cmtt}{bx}{n}{<-> ssub * cmtt/m/n}{}
\DeclareFontShape{OT1}{cmss}{m}{it}{<->ssub*cmss/m/sl}{}
\DeclareFontFamily{OMS}{cmtt}{\skewchar\font'60}
\DeclareFontShape{OMS}{cmtt}{m}{n}{<-> ssub * cmsy/m/n}{}
\DeclareFontShape{OMS}{cmtt}{bx}{n}{<-> ssub * cmsy/b/n}{}

\setlength{\textwidth}{355pt}
\addtolength\marginparwidth{30pt}
\addtolength\oddsidemargin{20pt}
\addtolength\evensidemargin{20pt}

\makeatletter
\def\cmd#1{\cs{\expandafter\cmd@to@cs\string#1}}
\def\cmd@to@cs#1#2{\char\number`#2\relax}
\DeclareRobustCommand\cs[1]{\texttt{\char`\\#1}}
\makeatother

\setcounter{StandardModuleDepth}{1}


\usepackage{2sidedoc}

\newcommand\B{\penalty300\relax}
\DeclareTextFontCommand{\textcmtt}{\usefont{OT1}{cmtt}{m}{n}}
\newcommand\package[1]{\textsf{#1}}
\CodelineNumbered


\makeatletter
\newenvironment{cmdusage}{%
   \setbox\z@=\vbox\bgroup
      \color@begingroup
      \hsize=0.75\textwidth
      \parindent=-1em%
      \everypar={\hangindent=1em\hangafter=0}%
      \rightskip=\z@ \@plus 1fil\relax
      \let\par\@@par
}{%
      \color@endgroup
   \egroup
   \@@par
   \medskip
   \noindent
   \fbox{\usebox\z@}\@@par
   \medskip
}
\makeatother

\newcommand*{\marg}[1]{%
   \begingroup\MacroFont\char`\{\endgroup
   \meta{#1}%
   \begingroup\MacroFont\char`\}\endgroup
}
\newcommand*{\oarg}[1]{%
   \begingroup\MacroFont\char`\[\endgroup
   \meta{#1}%
   \begingroup\MacroFont\char`\]\endgroup
}

\MakeShortVerb{\|}


\title{The \package{relenc} package}
\author{Lars Hellstr\"om%
  \thanks{E-mail: \texttt{Lars.Hellstrom@math.umu.se}}%
}

\begin{document}

\maketitle

\tableofcontents

\section{Motivation}
\label{Motivation}
%
This paper is about some shortcomings that, in my humble opinion, 
exists in the way \LaTeX\ handles fonts. I also point out a way in 
which these shortcomings can be overcome.

The primary problem is ligatures, but as there are a few different 
ligature concepts that are of interest, let me begin with specifying 
my terms. A \emph{ligature} is a sequence of characters 
(almost always letters) that have been given an appearance somewhat 
different from the one the characters would have if simply put side to 
side, almost always because they would otherwise not look very 
pleasing to the eye. Despite this difference in appearence, it is 
still meant to be read as the entire character sequence, not as a 
completely new character. The canonical example of this is the `fi' 
ligature.

In \TeX\ fonts, there is a special mechanism to implement this, and 
everything that is implemented using this mechanism will be 
called \emph{font ligatures}. It is almost always the case however, 
that some font ligartures are not ligatures as defined above, but 
simply a handy way to type characters that are hard or impossible to 
type using a standard keyboard; the canonical example of this is the 
`\texttt{--}' (two hyphens) to `--' (endash) conversion that is 
present in most \TeX\ fonts. Such nonproper ligatures will be called 
\emph{syntactic ligatures}, and proper ligatures will sometimes be 
called \emph{aestetic ligatures} to stress their origin.

A \emph{font-dependent command} in \LaTeX\ is a command whose 
actions depend directly or indirectly on which font is the current. (I 
would not consider a command |\foo| defined by
\begin{verbatim}
  \def\foo{\char65 }
\end{verbatim}
as a font-dependent command since it always does the same thing. 
The results need not always be identical, but that is because 
the command is executed under different conditions.) An example of a 
font-dependent command is |\"|, which is (roughly) |\accent 127| when 
the current font is \texttt{OT1}-encoded and |\accent 4| when the 
current font is \texttt{T1}-encoded. (The dependence is indirect since 
the command directly depends on a macro which is set during the font 
selection process, but there is a dependence.)

For the purposes of this paper, if would also suffice to define a 
font-dependent command as a command that is defined by some of the 
commands |\DeclareTextCommand|, |\ProvideTextCommand|, 
|\DeclareTextSymbol|, |\Declare|\B|Text|\B|Command|\B|Default|, 
|\Provide|\B|Text|\B|Command|\B|Default|, or |\Declare|\B|TextAccent|. 
\LaTeX\ documentation uses the term `encoding-specific command' for 
these, but for reasons that will soon be appearent, that term would be 
somewhat inappropriate here. 

Thus, with these definitions taken care of, it is now time to get to 
the point.

The recommended latin font encoding these days is the 
\texttt{T1}/`Cork'\slash`Extended \TeX\ text' 
encoding, and this is rightfully so. It is clearly superior to the old 
\texttt{OT1} encoding, as it adds more than a hundred accented 
characters to those which can be used to form a word that \TeX\ can 
automatically hyphenate, but there is at least one case in which the 
\texttt{OT1} encoding is preferable. This case is when the font has many 
ligatures.

In the \texttt{T1} encoding, there are seven slots available 
for ligatures, and these have been assigned to the `ff', `fi', `fl', 
`ffi', `ffl', `IJ', and `ij' ligatures. Since all slots have been 
assigned to something, there is no place to put an additional ligature, 
even if it is needed. Thus the conclusion is that if a font is to be 
\texttt{T1} encoded, it cannot contain any ligatures in addition to the 
aforemensioned; to put it the other way, if a font design requires the 
presence of a ligature other than the aforemensioned, it cannot be 
\texttt{T1} encoded.

In the \texttt{OT1} encoding, there are only five slots assigned to 
ligatures, but there are 128 unassigned slots that can be used for 
anything the font designer wants. Thus having more than five ligatures 
in an \texttt{OT1} encoded font is no problem, but a recourse to using 
\texttt{OT1} is not a very good option, as it leaves the hyphenation 
problem unsolved. The solution, then, would seem to be the creation of 
a new encoding, and part of it will, but this will not be quite 
sufficient for reasons I will shortly describe.

For the moment though, let us, as an intellectual experiment, assume 
that we shall solve this problem with \texttt{T1} having too few slots 
for ligatures by creating a new encoding for a hypothetical font that 
would need more than seven ligatures. Let us also assume that the new 
encoding shall be a modified version of the \texttt{T1} encoding, where 
some accented characters will have been left out to make room for the 
ligatures. Finally, let us assume that we want to be as international 
as possible and include as many of the accented characters as we can 
squeeze in. These are three simple assumptions, and there are good 
reasons for all of them.

How \emph{many} slots do we need to assign to ligatures, then? This 
varies, of course, between different font families, but it might vary 
\emph{even more} between fonts in the same family. The \texttt{it} 
shapes might need a few more than the \texttt{n} shapes, while the 
\texttt{sc} shapes might not need any at all (`\textsc{fi}' (|fi|) and 
`\textsc{f{}i}' (|f{}i|) look exactly the same in most font families). 
Instead, there are some accents which are harder to put on in the 
\texttt{sc} shapes (in many font families the ring on \textsc{a} in 
\textsc{\r{a}} should touch the main letter; this is not what the 
default definition does), so it appears that the optimal thing to do 
would be to have slightly different encodings for different fonts, even 
if they belong to the same family. This is theoretically no problem; 
\TeX's macro facilities are flexible enough to allow user level 
commands that do different things in different fonts. It becomes, 
however, a problem to do this in a reasonably universal way, so that 
the macros produced work in general and not only for a single font 
family.

Standard \LaTeX\ has a mechanism for doing precisely this. Using the 
commands |\DeclareTextCommand|, |\DeclareTextSymbol|, 
|\DeclareTextAccent|, or one of their relatives, one can give a 
definition of a command that is used with one particular font encoding 
and not with any other. The problem with using this mechanism here is 
that one might have to have the normal and italic variants declared 
as having different encoding attributes (as well as different 
shapes), so one would have to either device a whole new set of font 
changing commands or redefine \LaTeX's own high-level font changing 
commands (such as |\textit|) to change encoding as well as shape or 
series. Neither alternative is good, and one can expect several 
incompability problems to arise for both of them.

A better solution starts with recognizing that there are actually two 
different `encoding' concepts that can be found here. One is the 
attribute by which fonts are selected in \LaTeX, the other is the 
actual layout of a font. I will call this latter concept a 
\emph{coding scheme} and reserve \emph{encoding} for the former. 
(Formally, one may start by defining a \emph{slot} to be an integer in 
the range 0--255 and a \emph{glyph} to be a pattern (usually 
recognicable as a letter, digit, punctuation mark, or some other part 
of written language, but it need not always be). A coding scheme can 
then be defined as a mapping of slots to classes of glyphs. A font 
complies to a particular coding scheme if, for every slot $n$ in the 
domain of the coding scheme, the glyph occupying slot $n$ of the font 
is a member of the class that the encoding scheme maps $n$ to. But I 
digress.) As far as I know, there is no strict defintion of what an 
encoding is, apart from the operational given in \cite{fntguide} as 
something that is part of the specification of a font. (The canonical 
source for such a definition would be \cite{encguide}, but that paper 
is, according to its author, ``still in an embryo state''.) In font 
discussions, an encoding is often taken to imply a specific coding 
scheme, and many encoding definition files seem to be all about listing 
the coding scheme, but is this implication suitable? I would claim that 
in this case, it is not.

A more constructive definition would be to see an encoding as a 
specification of which font-dependent commands are available to the 
author. An encoding definition file, on the other hand, is a 
specification of the interface between \LaTeX\ macros and the 
information in a \TeX\ font. It does not matter to the author whether 
\H{o} is |\char174| of the current font, generated as |\accent125o| 
by \TeX, or whatever. The only thing that matters is that when the 
author types |Erd\H{o}s|, it comes out as Erd\H{o}s.

Consequently, there is really no need for the font-dependent commands in 
\LaTeX\ to do the same thing for any two fonts with the same encoding 
attribute, it is merely the case that standard \LaTeX\ does not offer 
an interface for defining font-dependent commands in any other way. The 
natural remedy for this then, would be to write a package which offers 
such an interface. This is what I have done; the package is called 
\package{relenc} and this paper is its documentation. Its usage and  
implementation are described in the following sections, and the 
appendices describe some accompanying files.

I shall however conclude this section by an attempt to elaborate the 
above view on what an encoding is, or perhaps rather, what it should be.

The encoding property of a font is a set of rules that determines how 
the author's manuscript is interpreted---the input character 
\texttt{q} for example has not the same interpretation in a 
\texttt{T1} encoded font (where it is the letter `q') as in an 
\texttt{OT2} encoded font (where it is a cyrillic letter whose closest 
latin equivalent is the Czech `\v{c}'). An encoding specification should 
therefore be a formalization of an agreement between the font designer 
on one hand and the author on the other---it specifies which rules each 
side must comply with and which results that can then be expected. An 
example of the author's rules may be to refrain from writing \TeX\ code 
like |\char 166|, because the font designer may have an option on what 
to put in that slot. If the author breaks the rules, he or she may find 
that the manuscript produced contains text whose meaning is not the same 
if typeset with two different fonts even if they do have the same 
encoding property. In practice, the author's rules for the standard text 
encodings are pretty much the same as the rules on how write \TeX\ code 
we find in every elementary book on the subject, so they are hardly new 
to us.

An example of the font designer's rules may be to put an exclamation 
mark in slot 33, so that \texttt{!} actually print as one, or to 
include a font ligature that converts two consequtive hyphens to an 
endash, so that |--| actually will print as an endash, which the 
author by tradition expects it to do. If the font designer breaks the 
rules then authors who follow their rules might find that they do not 
get the right results anyway and such a font designer is likely to get 
complaints from authors about this. In practice however, the font 
designer rules are often vaugely specified if specified at all and 
hence there are gray areas for most encodings where there are no rights 
and wrongs. The \texttt{OT1} encoding is probably the one most plauged 
by these; the dollar versus sterling problem (an excellent example of 
how changing the glyph of a single slot many completely alter the 
interpretation of a text) is a classic. One of my intentions with 
writing this text is to work for that these gray areas are shrunken 
or even completely eliminated, although I do not think there is 
anything that can be done for the \texttt{OT1} encoding---its 
irregularities are much too well known and exploited.

Now if an encoding is (a formalization of) an agreement, how do the 
parties agree to it? On the font designer's side this happens when 
the font designer gives a font a specific encoding by writing a font 
definition file that defines that font with that encoding. On the 
author's side this happens when the author selects a font with that 
encoding property.

So far the informal description, now it is time to get to the 
formalization. Which exactly are the rules for the author and for the 
font designer? This varies between different encodings, but only in 
the details. The areas the encoding specification must cover can be 
listed and are:
\begin{itemize}
  \item
    Which input characters that can be used directly to produce 
    some of the font's glyphs in the output and what they will 
    generate. This pertains to the author, who shouldn't use other 
    input characters. The allowed ones do however have well-defined 
    results.
  \item
    Which coding scheme the font must comply with. The pertains to 
    the font designer. There are no direct restrictions on the use of 
    slots not listed in this coding scheme.\footnote{There may be 
    indirect restrictions, see below.}
  \item
    Which the required syntactic ligatures are. This pertains to both 
    author and font designer. The author cannot trust any in addition 
    to these, the font designer must include them.\footnote{It could 
    well be that there \emph{should not} be any syntactic ligatures 
    in addition to these. I know of no situation where there would be 
    an advantage in adding syntactic ligatures.}
  \item
    Which the font-dependent commands are and what they will generate. 
    This pertains to the author in the same manner as does the input 
    character rules.
  \item
    Which the required font dimensions are and what they stand for. 
    This pertains to both the author and the font designer in the same 
    manner as does the syntactic ligature rules.\footnote{Even though 
    very few physical authors access any font dimensions, the same 
    does not hold for packages, and these also count as authors in 
    this context.}
\end{itemize}
After these have been specified, the grey areas should be very small 
indeed! There are however a few additional twists that must be sorted 
out.

If the required coding scheme listed in the encoding specification does 
not cover all the 256 slots, then one must be aware that in particular 
the required syntactic ligatures, but also the font-dependent commands, 
may impose some restrictions on the font's coding scheme in 
addition to those expressed by the given coding scheme that the font 
must comply with. These restrictions are then of the form that a 
glyph from a specific class must be assigned to some slot, but the 
font designer may freely choose exactly which slot. Thus any single 
slot not specified by the required coding scheme may be used for just 
about anything.

The use of the \package{relenc} package requires that the following 
area has to be added the ones listed above.
\begin{itemize}
  \item
    The font designer must see to that for every combination of a 
    variable command and a font, there is a variant that will give the 
    specified result.\footnote{The terms \emph{variable command} and 
    \emph{variant} are explained in Subsubsection~\ref{Tekn.bakgr.}.}
\end{itemize}
% With encodings that depend on the \package{relenc} package (I call 
% such encodings \emph{relaxed}), 
Hyphentation patterns do also offer theoretical problems to the use of 
the \package{relenc} package, as these refer explicitly to the coding 
scheme of the font. Problems with these can however not result in 
anything worse than bad hyphenation, so the interpretation of a text 
should not be affected. It is furthermore the case that in practice 
the problems can often be avoided (see Subsection~\ref{Hyph}).

Finally, there are two font parameters---|\hyphenchar| and 
|\skewchar|---that do explicitly relate to the coding scheme of the 
font and which are not stored in the font itself. It is possible that 
the value of at least one of these should be specified in an 
encoding specification, but that particular question is not of 
immediate interest to the \package{relenc} package, as \LaTeX\ itself 
already provides the font designer with the ability to set these for 
each font individually (using the sixth argument of 
|\Declare|\B|Font|\B|Shape|).



\section{Usage}

\subsection{Author usage}

All the author has to do to use fonts with a relaxed encoding, as 
opposed to fonts with for example the \texttt{T1} encoding, is to 
include the command
\begin{verbatim}
  \usepackage{relenc}
\end{verbatim}
in the preamble and load the encoding definition file, for example 
using the \package{fontenc} package. It is however important that the 
\package{relenc} package is loaded \emph{before} the encoding 
definition file, as the latter uses commands defined in the former.


\subsection{Font designer usage}

For a font designer, it is important to know at least in broad 
outline how the mechanisms made available through the \package{relenc} 
package work, which is why this subsection starts with a description of 
that. There is however a convention followed in the remainder of this 
paper that the reader should be aware of and this convention has to do 
with how control sequences are written.

In this paper, there are many control sequences with ``strange'' 
names, meaning names that mixes letters and non-letters in pretty 
arbitrary ways, so that these names cannot be read as one normally 
reads \TeX\ code. Therefore thin spaces are inserted around names of 
control sequences, regardless of whether a space character at that 
place would automatically be skipped by \TeX\ while it is reading the 
code or not. A space character that is really meant to ``be there'' will 
be written as a visible space (\textvisiblespace). All control sequences 
will, as usual, be written with an opening backslash, but this 
backslash is not part of the name of the control sequence.

Excepted from the above convention about spaces is the actual \TeX\ %
source code for that appear in Section~\ref{Implementation} and onwards 
(the lines of this is numbered, so it should be easily distinguishable) 
and some pieces of ``alternative'' source code in the same sections. 
These exceptions should be easy to recognise for the readers who are 
interested in that particular material.


\subsubsection{Some technical background}
\label{Tekn.bakgr.}

The main feature added by the \package{relenc} package is that of 
the \emph{variable commands}; it is through making commands variable 
that their definition may depend on which font is the current. This is 
not how \TeX\ would see it, since the definition of a variable 
command (as a \TeX\ control sequence) actually does not change after 
the command has been made variable! Rather, a variable command is a 
macro which expands to different things depending on which the current 
font is.

With overwhelming probability, this is something you have encountered 
before, although you might not have realised it. Under \LaTeXe, all 
accenting commands and all commands for letters other than a--z (such 
as \ae, \o, and \ss) are like this. The only difference lies is what 
will affect the eventual outcome of the command. The \LaTeXe\ kernel 
only supports dependence on which the current encoding is. The variable 
command concept makes dependence on the current family, series, and 
shape possible as well.

Both systems are quite similar in that they rely on |\csname| lookups. 
What happens to, for example, the command |\foo| is the following: 
First it gets |\string|ed. This converts the single control sequence token 
to the sequence of character tokens which would form the name of the 
command; in this case to |\|, |f|, |o|, and |o|. Then a piece of text 
is put in front of that character sequence, and finally the result of 
that is taken to be the name of a new control sequence. This process 
mainly generates control sequnces with very peculiar names; if the bit 
of text is, say, |T1| then the new control sequnce will be |\T1\foo| 
(this is \emph{one} control sequence). Such names are impossible to type 
without a lot of trickery, but that is deliberate, since they should 
not be accessed directly. If the control sequence thus formed is defined, 
then the definition of that control sequence will be taken as the intended 
definition of the control sequence |\foo| it all started with.

The systems differ in what pieces of text they put before the name of 
the command and what they do if the control sequence formed is not 
defined. The \LaTeXe\ kernel starts by using the name of the current 
encoding as the prefix text. If that fails, it tries with |?| instead. 
If that fails too, an error message is issued. The variable commands 
defined using the \package{relenc} package have a more general approach.

This approach relies on the concept of a \emph{search path}, about 
the structure of which more will be said later. For the moment, it is 
sufficient to say that it consists of a sequence of \emph{blocks} of 
text. The looking up process consists of a loop in which the following 
is done: The first block is removed from the search path, and the text 
it contains is used to form the name of a control sequence, as described 
above. The rest of the search path is saved away as the \emph{remaining 
search path}. If the control sequence formed is defined, then it is used 
as the definition of the command, and if it is not, then the process 
is repeated. When the process is repeated however, it starts by 
removing the first block of the remaining search path, which is the 
second (or third, or fourth, depending on which iteration of the loop 
is the current) block of the entire search path, while once again 
saving the rest as the new remaining search path. Not until the 
entire search path has been scanned in this way will an error message 
be issued.

This means arbitrarily many possibilities can be tested in searching 
for the definition of a command, but about six is probably a 
realistic upper bound on how many there will be in practical 
applications. In many cases it will be even fewer.

What has been mensioned so far does not mean there necessarily is any 
dependence on the current font, but it opens the possibility. The 
trick is that the pieces of text, which are the blocks in the search 
path, can contain not only characters but also macros (and other 
expandable stuff)---as long as everything eventually expands to 
character tokens, everything is fine. The point here is that the 
control sequences that contains the names of the current encoding, 
family, series, and shape---|\f@encoding|\footnote{For technical 
reasons, it is probably better to use \cs{cf@encoding} instead. See page 
\pageref{Why cf@encoding} for a discussion of this.}, |\f@family|, 
|\f@series|, and |\f@shape| respectively---are of this kind. Thus 
making the definition of a variable command depend on these attributes 
of the current font is simply a matter of making the corresponding 
control sequences part of the texts in the search path.

The above might give the impression that the variable commands are 
ment to be used instead of the encoding-specific commands of standard 
\LaTeX, but that is not the case. What actually happens is that the 
control sequences of type |\T1\foo| that the \LaTeXe\ kernel looks up 
will themselves be variable commands. This means that to \LaTeX, the 
commands in a relaxed encoding whose definitions depend on the current 
font are just normal encoding-specific commands, even though they do a 
lot of peculiar things before they actually generate any typeset 
material, but on the other hand \LaTeX\ doesn't care what they do, as 
long as it finds a definition.\footnote{It also saves me a lot of 
work, since I won't have to bother with trying to make the variable 
commands robust---\LaTeX\ already makes the encoding-specific commands 
robust.}

This has probably been a bit abstract, so an explicit example might be 
in place. Let's say that the current encoding is \texttt{T1R} (this is 
an existing relaxed encoding), the current family is \texttt{zcm} 
(this is an example family\footnote{The \texttt{zcm} font family is 
described in Appendix \ref{zcm-family}.}), the current series is 
\texttt{m}, and the current shape is \texttt{n}. Furthermore let's say 
the user has just issued the font-dependent command |\foo| (this is not 
really a font-dependent command, but let's assume it is). What will happen?

\begin{enumerate}
\item
  The actual control sequence |\foo| causes the \LaTeXe\ kernel to start 
  look for a definition. It first tries |\T1R\foo|, then |\?\foo|, and 
  if neither is defined then an error message is given. The case of 
  interest here is that |\T1R\foo| is defined, because then the 
  \LaTeXe\ kernel is content and \TeX\ will act as if |\T1R\foo| was 
  issued instead.
\item
  If the final definition of |\foo| is to depend on family\slash 
  series\slash shape then |\T1R\foo| must be a variable command. The 
  first thing which happens then is that \package{relenc} starts 
  looking for a search path to use. Search paths are stored in 
  macros, and the names of these macros are formed in a manner 
  similar to that in which the other lookup names here are formed.
  
  The two macros which can contain the search path are 
  |\T1R/zcm-path| and |\T1R-path| (these are still only single 
  control sequences), and they are tried in that order. If none of 
  them exists, then an error message is given. The second of the two 
  is common to all fonts using the \texttt{T1R} encoding and must be 
  defined by the encoding designer. A font designer can choose to 
  define a search path of his or hers own, and that will then be named 
  as the first of the two above. A family specific search path 
  completely overrides the encoding specific (the latter is in that 
  case not even considered), but in many cases the encoding specific 
  will do just fine.
  
  Let's assume that |\T1R/zcm-path| is defined and consists of
  \begin{verse}
    |{|\meta{enc}|/|\meta{family}|/|\meta{series}|/|\meta{shape}|}|\\
    |{|\meta{enc}|/|\meta{family}|/?/|\meta{shape}|}|\\
    |{|\meta{enc}|/|\meta{family}|/?/?}|\\
    |{|\meta{enc}|/?/?/?}|
  \end{verse}
  (Each block is written on a separate line. The text of the block is 
  everything between (but not including) the braces, which act as 
  delimiters of the block. \meta{enc}, \meta{family}, \meta{series}, and 
  \meta{shape} denote the \LaTeX\ macros listed above which contain the 
  names of the current encoding, family, series, and shape respectively.)
\item
  Once the search path is found, it is scanned. In this particular 
  case this means that the control sequences |\T1R/zcm/m/n\foo|, 
  |\T1R/zcm/?/n\foo|, |\T1R/zcm/?/?\foo|, and |\T1R/?/?/?\foo| are 
  tried in that order. If none of them is defined, an error message is 
  given, but let's assume that |\T1R/zcm/?/?\foo| is defined and 
  neither |\T1R/zcm/m/n\foo| nor |\T1R/zcm/?/n\foo| are. This 
  corresponds to the case that there is a definition of the variable 
  command that is specific for the family, but not any specific for 
  the shape or series.
\item
  The final stage is that |\T1R/zcm/?/?\foo| gets executed.
\end{enumerate}

There are now only a few more things to sort out before the 
description of the commands a font designer has available can commence. 
Firstly, control sequences like the above |\T1R/zcm/?/?\foo|, that hold 
an actual definition of a variable command, are called \emph{variants} 
of that command. The processing during the scan of the search path that 
is connected to one block in the search path is called a \emph{step} in 
that scan.

Secondly, there is another thing which might affect the definition of a 
command, viz.\ the first argument of the command. Commands for which 
the first argument is checked before the actual definition is determined 
are called \emph{composite commands}, or are said to be \emph{composed}. 
The alternative definitions of them are called \emph{compositions}. Each 
composition is used for exactly one value of the argument, and the main 
composite command contains a definition which is used for all values for 
which there is no composition.

This too is a mechanism that is present in the \LaTeXe\ kernel, what 
\package{relenc} does is that it introduces some commands to make 
variable commands composed or vice versa. Very much like variable 
commands, composite commands rely on |\csname| lookups, but instead of 
adding a prefix to the command name, the composition mechanism adds a 
suffix consisting of a hyphen (|-|) and the first token of the first 
argument (as a precaution, this token is |\string|ed beforehand, to 
convert it to character tokens if it was not already).

An example of this, from the \texttt{T1} encoding, is the acute accent 
command |\'|. The command that actually is composed is |\T1\'|, which 
holds the definition of |\'| in the \texttt{T1} encoding, and one of 
its compositions are |\\T1\'-a|. This is a macro which expands to the 
letter \'{a}, which is the expected result of |\'{a}|. There is no 
composition for the argument |\ae| in the \texttt{T1} encoding, so if 
the user issues |\'{\ae}| the lookup mechanism finds nothing and the 
default definition is used, yielding `\'{\ae}'. Had there been a 
composition however, it would have called |\\T1\'-\ae|. Cases like 
these are why the |\string|ing precaution is necessary; most 
commands generate errors when \TeX\ meets with them inside a |\csname| 
\textellipsis\ |\endcsname| pair.

With that description completed, it is now time to describe the usage 
and purpose of the commands available to the font designer. It should 
perhaps be pointed out that most of them are about defining variants 
of commands, as making a command variable lies within the powers of 
the encoding designer.


\subsubsection{Defining variants of font-dependent commands}

Among the arguments of every variant defining command is the sequence 
\marg{encoding}\B\marg{family}\B\marg{series}\B\marg{shape}, 
which specifies which variant of a command is being defined. The 
arguments should consist of letters and\slash or figures, but any 
combination of these parameter fields might be left empty. A field 
left empty signifies that the intended variant may be used regardless 
of what value that attribute may take. Thus |{T1R}{zcm}{m}{n}| is used 
when defining a variant specific to this encoding, family, series, and 
shape, whilst |{T1R}{zcm}{}{}| is used when defining a variant that 
applies for every font in the \texttt{T1R}-encoded \texttt{zcm} family. 
Technically, a field left empty will be filled with a question mark. 
Thus the |{T1R}{zcm}{}{}| variant of |\foo| will be stored in the 
control sequence |\T1R/zcm/?/?\foo|.

\DescribeMacro\DefineTextSymbolVariant
\DescribeMacro\DefineTextAccentVariant
|\DefineTextSymbolVariant| and |\DefineTextAccentVariant| are the two 
simplest commands for defining a variant. The former makes the variant 
output a single character, whose slot in the font is given as the 
argument \meta{slot}. The latter should be used for variants of accent 
commands, as an accenting command is precisely what it defines. The 
character used for the accent is the one with slot number 
\meta{slot}. |\DefineTextSymbolVariant| and 
|\DefineTextAccentVariant| parallell the commands |\DeclareTextSymbol| 
and |\DeclareTextAccent| respectively that are found in standard 
\LaTeX.

\DescribeMacro\DefineTextCommandVariant
If the above are not sufficient for the definition of a variant of 
some command (they are not, for example, general enough to define any 
of the accents put \emph{under} letters), complete generality is 
offered through the |\DefineTextCommandVariant| command, which can be 
used to define any \TeX\ macro. (It consists simply of a |\gdef| to 
the control sequence that stores the variant in question.) This means 
the \meta{parameter text} should be formated as for the |\def| 
command, without any surrounding braces or such. Also notice that every 
token in the \meta{parameter text} counts, including spaces and end of 
lines.

Apart from the arguments mensioned, all the above commands have an 
argument \meta{cmd}. This is the name of the base font-dependent command of 
which you want to define a variant. It is not the name of the actual 
variable command, so you should write |\foo|, not |\T1R\foo|. 
The syntaxes of the commands are as follows:
\begin{cmdusage}
  |\DefineTextSymbolVariant| \marg{cmd}
  \marg{encoding} \marg{family} \marg{series} \marg{shape}
  \marg{slot}
  
  |\DefineTextAccentVariant| \marg{cmd}
  \marg{encoding} \marg{family} \marg{series} \marg{shape}
  \marg{slot}
  
  |\DefineTextCommandVariant| \marg{cmd}
  \marg{encoding} \marg{family} \marg{series} \marg{shape}
  \meta{parameter~text}~|{|~\meta{replacement~text}~|}|
\end{cmdusage}
\medskip

\DescribeMacro\NewTextCommandVariant
\DescribeMacro\RenewTextCommandVariant
\DescribeMacro\ProvideTextCommandVariant
\package{relenc} does also offer some |\newcommand|-style commands for 
defining variants of font-dependent commands, for font designers who prefer 
that. They do offer some additional functionality, as they can make 
commands which take an optional argument, but I am not currently aware 
of any font-dependent command that uses this feature. One reason the 
feature is offered is that variable command processing comes before 
optional argument processing, hence if a variable font-dependent command 
can have an optional argument then all its variants must be able to cope 
with that argument when it is present.

Technically the commands boil down to an application of 
|\newcommand|, |\renewcommand|, or |\providecommand| respectively 
(the starred forms, to be exact). Thus you may get error messages 
if the variant is already defined or not defined, depending on which 
command you use. As the error messages are the standard \LaTeX\ %
error messages, they may be somewhat confusing. Still, a somewhat 
confusing error message may be better than none at all.
\begin{cmdusage}
  |\NewTextCommandVariant| \marg{cmd}
  \marg{encoding} \marg{family} \marg{series} \marg{shape}
  \oarg{numargs} \oarg{default} \marg{replacement text}
  
  |\RenewTextCommandVariant| \marg{cmd}
  \marg{encoding} \marg{family} \marg{series} \marg{shape}
  \oarg{numargs} \oarg{default} \marg{replacement text}
  
  |\ProvideTextCommandVariant| \marg{cmd}
  \marg{encoding} \marg{family} \marg{series} \marg{shape}
  \oarg{numargs} \oarg{default} \marg{replacement text}
\end{cmdusage}
\medskip


\subsubsection{Defining variants of compositions}
\label{Var. of comp.}

As compositions can be variable, there are commands for defining 
variants of them. The situation here is simpler than for font-dependent 
commands in general since compositions cannot have any arguments, 
consequently there is no need to provide such a large variety of 
definition commands as for defining command variants.

\DescribeMacro\DefineTextCompositionVariant
\DescribeMacro\DefineTextCompositionVariantCommand
The most important is |\DefineTextCompositionVariant| which 
corresponds to |\DefineTextSymbolVariant|---it makes a variant which 
simply typesets one of the characters in the font. The most general 
command is |\DefineText|\B|Composition|\B|VariantCommand| which defines 
the variant to be a parameterless macro without other restictions.

\DescribeMacro\DefineTextUncomposedVariant
A special, but probably rather common macro to define a variant of a 
composition to be, is the macro consisting of the noncomposite 
definition applied on the argument for the composition, because 
defining the variant this way is probably the easiest way to free a slot 
in the font for other purposes. Hence there is a special command for 
doing this: |\DefineTextUncomposedVariant|. It resembles the other 
two, but there is of course no argument that gives the definition of 
the variant and there is a special restriction, namely that 
the \meta{encoding} argument must not be empty!

The arguments of these commands are as for the commands for defining 
variants of font-dependent commands, except for one designated 
\marg{argument}. This is the argument which is passed to the 
font-dependent command that corresponds to the current composition---the 
composition of which a variant is to be defined.

\begin{cmdusage}
   |\DefineTextCompositionVariant| \marg{cmd}
  \marg{encoding} \marg{family} \marg{series} \marg{shape}
  \marg{argument} \marg{slot}
  
   |\DefineTextCompositionVariantCommand| \marg{cmd}
  \marg{encoding} \marg{family} \marg{series} \marg{shape}
  \marg{argument} \marg{replacement text}
  
  |\DefineTextUncomposedVariant| \marg{cmd}
  \marg{encoding} \marg{family} \marg{series} \marg{shape}
  \marg{argument}
\end{cmdusage}


\subsubsection{Defining compositions of variants}
\label{Comp av var}
%
Things can be done the other way round too---a variant of a font-dependent 
command may have compositions. These compositions are then completely 
independent of any compositions of the base font-dependent command. Unlike 
compositions of a font-dependent command (which must be \emph{declared} 
in the encoding definition file and are common to all fonts in a 
particular encoding), compositions of a variant can be \emph{defined} 
whenever a variant can be defined. Thus making compositions of variants 
lies within the powers of the font designer.

\DescribeMacro\DefineTextVariantComposition
\DescribeMacro\DefineTextVariantCompositionCommand
There are two commands for defining compositions of variants: 
|\Define|\B|Text|\B|Variant|\B|Composition| and 
|\Define|\B|Text|\B|Variant|\B|Composition|\B|Command|. The difference 
between them is simply that the latter command defines the composition 
to be a macro with the given replacement text, while the former defines 
it to be a chardef token for the given slot. What is more interesting is 
what these commands do if the variant they are to make a composition of 
is not defined, because in this case they define the default definition 
to be a macro that resumes the scan of the search path. This means that 
the font designer can choose to specify some compositions early in the 
search path and others later---and perhaps more importantly---can give 
special definitions for some compositions early in the search path 
without having to copy the default definition to that level.

As it happens, the names of the control sequences, in which the 
definitions of compositions of variants and variants of compositions 
respectively are stored, are slightly different (a backslash appears 
at different positions). Hence it is possible to have both for exactly 
the same \meta{encoding} \meta{family} \meta{series} \meta{shape} 
\meta{argument} combination for a composition of variant and variant 
of composition without having them overwriting each other, although 
there is hardly any point in having things set up this way.

\begin{cmdusage}
   |\DefineTextVariantComposition| \marg{cmd}
   \marg{encoding} \marg{family} \marg{series} \marg{shape} 
   \marg{argument} \marg{slot}
   
   |\DefineTextVariantCompositionCommand| \marg{cmd}
   \marg{encoding} \marg{family} \marg{series} \marg{shape} 
   \marg{argument} \marg{replacement text}
\end{cmdusage}


\subsubsection{Setting the family search path}

Setting the family search path is pretty straightforward: The search 
path is the last argument, encoding and family in question the two 
other. A useful feature here is that inside the search path argument, 
|@| will be a letter and all spaces and newlines are ignored. This 
means the example search path from Subsubsection \ref{Tekn.bakgr.} can 
be set even by a command call as spaced out as the following
\begin{verbatim}
  \SetFamilySearchPath{T1R}{zcm}{
     { \cf@encoding / \f@family / \f@series / \f@shape }
     { \cf@encoding / \f@family / ? / \f@shape }
     { \cf@encoding / \f@family / ? / ? }
     { \cf@encoding / ? / ? / ? }
  }
\end{verbatim}
and even if it appears in the preamble of a document (this is handy when 
debugging a font family).

Search paths \emph{must} be set using the |\SetFamilySearchPath| or 
|\SetEncoding|\B|SearchPath| commands, otherwise the case that no 
definition of a variable command is found cannot be handled 
correctly, with the effect that \TeX\ gets hung in an infinite loop.

\begin{cmdusage}
   |\SetFamilySearchPath| \marg{encoding} \marg{family}
   \marg{search~path}
\end{cmdusage}


\subsubsection{Where to put it all}
%
One topic that has not been delt with above is where the font designer 
is to put all these commands for defining variants and setting search 
path. In my opinion, there is only one possible place---the font 
definition file\footnote{I am well aware of the rules for which 
commands may be used in font definition files that are described in 
\cite{fntguide}. I have however chosen to disregard from these rules 
in the case of commands defined by the \package{relenc} package, as 
this case could hardly have been foreseen by the prescribers of these 
rules.}. This is also the logical place to put the commands, 
since this is the file in which the font designer describes his or her 
font family to \LaTeX. In particular, one cannot expect full 
functionality if the commands are put in a package, since it is 
perfectly possible to select a font without using a standard package 
for this.

Of course, definition commands can also appear in an encoding 
definition file and anything that can appear in an encoding definition 
file may also appear in a package file, even though packages containing 
such code are often of a rather special nature.

% There is however a complication of a technical nature with using 
% commands from the \package{relenc} package in font definition files. 
% Most of the commands defined in the \package{relenc} package assume 
% that the value of the \TeX\ parameter |\escapechar| is $92$, denoting 
% the backslash character (|\|). This is normally the case in \LaTeX, 
% but unfortunately this is not always the case when a font definition 
% file is loaded. \LaTeX\ locally sets |\escapechar| to $-1$ during some 
% important operations, most notably the loading of a new font done in 
% |\define@newfont|, and it is often at this time that font definition 
% files get loaded.
% 
% To work around this, include the line
% \begin{verbatim}
%   \begingroup \escapechar=`\\
% \end{verbatim}
% somewhere in every font definition file using commands from the 
% \package{relenc} package and put it before the first such command; also 
% include the line
% \begin{verbatim}
%   \endgroup
% \end{verbatim}
% somewhere after the last such command. This temporarily resets 
% |\escapechar| to its normal value. I believe the group is necessary 
% (and it doesn't harm), since the value of |\escapechar| is not 
% neccessarily $-1$ at the time a font definition file is loaded. Sigh.
% 
% IMHO, the best way to fix this would be to change \LaTeX\ itself so 
% that it doesn't change |\escapechar| at this particular 
% time\footnote{One could easily achieve the same results using a 
% combination of \cs{expandafter}s and \cs{@gobble}s. This would also 
% have the positive effect that backslashes will appear where one is 
% used to see them in the tracing messages \TeX\ writes out if 
% \cs{tracingcommands} or \cs{tracingmacros} are positive, instead of 
% being missing inside a neighbourhood of every font change.}, but that 
% is of course for the \LaTeX3 project team to decide.
 

\subsection{Encoding designer usage}
%
The encoding designer's work in making a relaxed encoding is very 
much like the work in making a normal encoding. There are only two 
additional steps: It must be decided which commands and compositions 
that should be variable, and an encoding search path must be set. Both 
of these are more a matter of planning than writing \TeX\ code, but it 
seems best to treat the coding first.

Each of the commands for declaring a variable font-dependent command or 
composition corresponds to a command for declaring a non-variable 
font-dependent command which is part of standard \LaTeX, as is shown in the 
following table. The correspondence is not one to one, but it is pretty 
close.

\begin{center}
  \small\DeleteShortVerb{\|}
  \begin{tabular}{|ll|}
    \hline
    Standard declaration command&  Variable declaration command%
      \\[-0.9\ht\strutbox]
    \hrulefill&\hrulefill\\
    \relax\MakeShortVerb{\|}|\DeclareTextCommand|& 
                    \relax|\DeclareTextVariableCommand|\\
    \relax|\DeclareTextCommand|& 
                    \relax|\DeclareTextVariableCommandNoDefault|\\
    \relax|\ProvideTextCommand|& 
                    \relax|\ProvideTextVariableCommand|\\
    \relax|\DeclareTextSymbol|& 
                    \relax|\DeclareTextVariableSymbol|\\
    \relax|\DeclareTextAccent|& 
                    \relax|\DeclareTextVariableAccent|\\
    \relax|\DeclareTextComposite|& 
                    \relax|\DeclareVariableTextComposition|\\
    \relax|\DeclareTextCompositeCommand|& 
                    \relax|\DeclareVariableTextComposition|\\
    \hline
  \end{tabular}
\end{center}

\DescribeMacro\DeclareTextVariableSymbol
\DescribeMacro\DeclareTextVariableCommand
\DescribeMacro\ProvideTextVariableCommand
\DescribeMacro\DeclareTextVariableAccent
The difference between on one hand the commands |\Declare|\B|Text|\B
|Variable|\B|Symbol|, |\Declare|\B|Text|\B|Variable|\B|Command|, 
|\Provide|\B|Text|\B|Variable|\B|Command|, and |\Declare|\B|Text|\B
|Variable|\B|Accent| and their non-variable counterparts on the other is 
that the font-dependent command they declare will become a variable 
command, while the definitions given will be used to define the 
encoding-level variant of the command. The arguments are exactly the 
same as for the commands' non-variable counterparts of standard \LaTeX.

\DescribeMacro\DeclareTextVariableCommandNoDefault
The |\DeclareTextVariableCommandNoDefault| command only declares a 
font-dependent command and makes it variable, but does not define any of 
its variants. This can actually be useful if one is writing an encoding 
that is a relaxed version of another encoding, such as the \texttt{T1R} 
encoding, since many commands will have the same encoding-level 
definition in both encodings. It is then possible to include the name of 
that other encoding in the search path, so that the same control 
sequence will hold the definition of a command in two different 
encodings.

\DescribeMacro\DeclareVariableTextComposition
The |\DeclareVariableTextComposition| command declares a composition of 
a command, like |\Declare|\B|Text|\B|Composite| or 
|\DeclareTextCompositeCommand|, and makes that composition variable. 
But it is also like |\Declare|\B|Variable|\B|Text|\B|CommandNo|\B|Default| 
in that it does not define any variant of the composition. To define a 
variant, one of the commands in Subsection \ref{Var. of comp.} must be 
used as well\footnote{I am not sure that this is a good way to organise 
it. Perhaps there should be commands combining these functions.}. 
|\DeclareVariableTextComposition| takes three arguments: the command, 
the encoding, and the argument for which a composition is to be 
declared.

\begin{cmdusage}
  |\DeclareTextVariableSymbol| \marg{cmd} \marg{encoding} 
  \marg{slot}
  
  |\DeclareTextVariableCommand| \marg{cmd} \marg{encoding} 
  \oarg{arguments} \oarg{default} \marg{replacement~text}
  
  |\DeclareTextVariableCommandNoDefault| \marg{cmd} \marg{encoding}
  
  |\ProvideTextVariableCommand| \marg{cmd} \marg{encoding} 
  \oarg{arguments} \oarg{default} \marg{replacement~text}
  
  |\DeclareTextVariableAccent| \marg{cmd} \marg{encoding} 
  \marg{slot}
  
  |\DeclareVariableTextComposition| \marg{cmd} \marg{encoding} 
  \marg{argument}
\end{cmdusage}
\bigskip

\DescribeMacro\SetEncodingSearchPath
This is very much like |\SetFamilySearchPath|; the main difference to 
setting a family search path is that a relaxed encoding \emph{must} set 
its encoding search path. 

\begin{cmdusage}
   |\SetEncodingSearchPath| \marg{encoding} \marg{search~path}
\end{cmdusage}

\medskip

Now to the part which is not coding. As noone, at the time this is 
written, is particularly experienced in the creation of relaxed 
encodings, this is not a guide of how to do that. This is only a 
collection of some observations I made when I created the 
\texttt{T1R} encoding and the \package{relenc} package.

\begin{itemize}
  \item
    When making a relaxed encoding: If you mainly want to free some 
    slots, so that you can include some new set of glyphs (for example 
    additional ligatures) in the font, the obvious place to start is to 
    reduce the number of slots that are assigned to compositions, by 
    implementing these in a variable way. 
  \item
    When relaxing a composition, there are two ways of doing this: 
    making the composition variable, or making the command variable 
    and defining a composition of some variant. The cost (i.e., the 
    number of special definitions you have to make) is connected to 
    different things in these methods.
    
    In the case of a composition of a variant, there is a cost 
    connected to having a composition. In the case of a variable 
    composition, the cost is rather connected to not using the default 
    definition for the composition. In the usual case that one either 
    uses a special glyph for a composition or uses the default 
    definition of the accenting command, this means that composition of 
    variant is cheaper if a minority of the compositions  uses the 
    default definition and variable composition is cheaper if a 
    majority uses the default definition.
  \item
    In some cases, the default definition of an accenting command 
    tends to be suitable for some font families, but inappropriate 
    for others. An example from the \texttt{OT1} encoding is that the 
    definition of |\c| starts by looking at the \emph{height} (!!!) of 
    the character it is to put a cedilla under. If the height is 
    exactly $1\,\textrm{ex}$ then the |\accent| primitive is used, 
    otherwise the accent is put in place using a |\vtop| construction. 
    This works fine (I suppose, trusting DEK to have known what he was 
    doing) for fonts with idealized heights and depths of characters, 
    such as the Computer Modern family of fonts, but is a pure waste 
    of time if the heights and depths are computed from the bounding 
    boxes of the glyphs (like \textit{fontinst} \cite{fontinst} does).
    
    The conclusion of all this is that it might be a good idea to 
    make accenting commands that have such a specific default definition 
    variable, regardless of how any compositions of these commands might 
    be implemented, so that font designers can override the definitions 
    in case they want to.

\end{itemize}

Apart from this, there is not much advice I can give. It is however 
likely to be a good idea to try to make a specification of the 
encoding---like described in Section \ref{Motivation} or in some other 
way, detailed or only in loose sketches---before starting to do the 
coding.


\subsection{Power user commands}
%
This subsection treats some commands that may be useful to advanced 
users of the \package{relenc} package (this includes all font and 
encoding designers); in any case, the novice author users can do 
perfectly well without using the commands described here.

\subsubsection{Debugging assistance}
%
\DescribeMacro\ShowVariantSearchResult
As the way from user level command to definition given is quite long 
if the command is variable, there are many instances in which things 
can go wrong. |\ShowVariantSearchResult| may help in sorting out what 
exactly happened. Its primary function is to print the contents of 
all internal variables in \package{relenc} on the terminal and then 
wait for a command, just like after the primitive \TeX\ command |\show|. 
As an extra service, |\ShowVariantSearchResult| also prints the current 
encoding, family, series, and shape.

As most of the processing in \package{relenc} is done in \TeX's mouth, 
there is not very much left to show. The most important piece of data 
there is is the \emph{remaining search path}. This is the part of the 
search path that was \emph{not} scanned in looking for a definition; 
by comparing it to the whole of the search path used, one can 
determine at which stage a definition was found. The other thing shown 
is the definition of |\RE@first@search@item|, which normally is 
defined to be a parameterless macro that expands to the first block 
in the search path most recently used. There are however two cases 
when it is not: (i) If a definition was found in the first stage 
of the most recent search, |\RE@first@search@item| is not altered. 
(ii) If the search has been restarted (see Subsubsection \ref
{Comp av var}) then |\RE@first@search@item| is a macro with a 
parameter.

Despite these reservations, |\ShowVariantSearchResult| provides about 
all the information there is to get about what a search has found. It 
might also be instructive if you want to understand the inner workings 
of the \package{relenc} package in more detail.

\begin{cmdusage}
  |\ShowVariantSearchResult|
\end{cmdusage}

Should |\ShowVariantSearchResult| not give you enough information, you 
can of course always set |\tracingmacros| to 1 and |\tracingcommands| 
to 2 for the time it takes to execute the command you are trying to 
debug, this will give you the whole picture of what \package{relenc} 
does. Before attempting this drastic action however, you should 
familiarise yourself with the implementation of the \package{relenc} 
package.


\subsubsection{The `define first' mechanism}
%
The `define first' mechanism, which has not been mensioned until now 
because it is not really related to anything else in the package, is 
something very few users should ever have to bother with. It can 
however speed up the typesetting process, as demonstrated in Table 
\ref{Tab:Tid}.

\begin{table}
  \begin{center}
    \DeleteShortVerb{\|}
  \begin{tabular}{|rr@{.}lr@{.}lr@{.}l|}
    \hline
    &\multicolumn{6}{c|}{Default encoding}\\[-0.9\ht\strutbox]
    &\multicolumn{6}{c|}{\hrulefill}\\
    & \multicolumn{2}{c}{\texttt{OT1}}&\multicolumn{2}{c}{\texttt{T1}}& 
      \multicolumn{2}{c|}{\texttt{T1R}}
      \\[-0.9\ht\strutbox]
    & \multicolumn{2}{c}{\hrulefill}& \multicolumn{2}{c}{\hrulefill}& 
      \multicolumn{2}{c|}{\hrulefill}\\
    \parbox[c]{0.3\columnwidth}{Time taken using \texttt{T1}}& 
      253&4\,s& 197&5\,s& 255&2\,s\\[1ex]
    \parbox[c]{0.3\columnwidth}{Time taken using \texttt{T1R}\\
        (DFM on, no FSP)}& 
      339&7\,s& 349&5\,s& 294&2\,s\\[2ex]
    \parbox[c]{0.3\columnwidth}{Time taken using \texttt{T1R}\\
        (DFM off, no FSP)}& 
      446&4\,s& 458&3\,s& 400&5\,s\\[2ex]
    \parbox[c]{0.3\columnwidth}{Time taken using \texttt{T1R}\\
        (DFM off, has FSP)}& 
      334&4\,s& 350&9\,s& 293&2\,s\\[2ex]
    \parbox[c]{0.3\columnwidth}{Time taken using \texttt{T1R}\\
        (DFM on, has FSP)}& 
      316&7\,s& 327&5\,s& 269&9\,s\\[2ex]
    \hline
  \end{tabular}%
    \MakeShortVerb{\|}
  \end{center}\medskip
  
  \begingroup\footnotesize \parindent=1em
    DFM = Define First Mechanism
    
    FSP = Family Search Path. The family search path used was 
    optimised to examine only the levels at which there actually 
    existed some variant.
    
    The `default encoding' in this table is the encoding whose 
    encoding definition file was read in last. As explained in 
    \cite{ltoutenc}, this means that all commands declared in that 
    encoding will execute somewhat faster when that encoding is the 
    current.
    
    The test text used consisted of all non-accented letters declared 
    in the \texttt{T1} encoding (a--z, as well as \ae, \ss, \i, and a 
    few others) in both upper and lower case, as they are as well as 
    accented with every accent command available (|\`|, |\'|, |\^|, |\~|, 
    |\"|, |\H|, |\r|, |\v|, |\u|, |\=|, |\.|, |\b|, |\c|, |\d|, and 
    |\k|). These 32 lines were then repeated 100 times, to reduce the 
    relaive amount of time taken to start the process.\par
  \endgroup
  
  \caption{A comparision of typesetting speed}\label{Tab:Tid}
\end{table}

What the define first mechanism (DFM) does, when it is active, is 
that if a definition is not found in the first step of the search 
path scan and a definition is found in some later step, then that 
definition is copied to the control sequence scanned in the first step. 
Thus the next time that the same command is issued, the scan of the 
search path will find a definition in the first step.

This can speed up the search considerably, but there is a price to pay: 
More control sequnces gets defined, meaning more of \TeX's memory is 
being used for storing definitions of variable commands.\footnote{Or 
so it would appear \textellipsis\ Some things I've recently learnt 
about how \TeX's internal tables work has made me wonder about whether 
it really takes more memory, so I am currently not sure. Perhaps 
someone competent in the area of \TeX's memory management will 
volunteer to sort things out for me?} If you run out of memory while 
typesetting a document with the DFM on, turning it off will lower the 
memory requirements. If your \TeX\ is generally low on memory however, 
you should probably not be using relaxed encodings at all, since the 
basic deal of the entire package is to loosen the restrictions on fonts 
for a particular encoding by increasing the number of control sequences 
needed for the typesetting process.

But these differences should be seen for what they really are, 
differences in speed for one of the many things \TeX\ have to do to 
typeset something. \TeX\ does no linebreaking during the tests in 
Table \ref{Tab:Tid} (hence no hyphentaing either), does not read any 
input after the first five seconds (the entire text is generated through 
expanding macros), has a very simple job pagebreaking, and so forth. 
In addition, the percentage of letters generated through font-dependent 
commands is much greater in the test text than what one would find in 
a normal \TeX\ manuscript. This circumstance also reduces the effect 
that the tabulated differences in speed will have on the overall 
typesetting speed for a normal \TeX\ manuscript.

If you have not noticed that your document is being typeset slower due 
to the fact that the encoding used is not the encoding whose definition 
file was read in last, then chances are you would not notice any drop 
in speed if it was typeset using a relaxed encoding either.

\medskip

\DescribeMacro\ActivateDefineFirst
\DescribeMacro\DeactivateDefineFirst
The DFM is turned on and off using the commands 
|\ActivateDefineFirst| and |\DeactivateDefineFirst|, none of which 
have any parameters. As it is currently implemented, the activation 
state of the DFM is affected by grouping, but the defining it does 
is global.

\begin{cmdusage}
  |\ActivateDefineFirst|
  
  |\DeactivateDefineFirst|
\end{cmdusage}


% The implementation
% \part{\texttt{relenc.dtx}}
\DocInput{relenc.dtx}\Finale


\appendix

\part*{The \texttt{T1R} encoding}
\addcontentsline{toc}{part}{The \texttt{T1R} encoding}
\DocInput{t1renc.dtx}\Finale

\part*{The \texttt{zcm} example font family}
\addcontentsline{toc}{part}{The \texttt{zcm} example font family}
\DocInput{t1rzcm.fdd}\Finale


\begin{thebibliography}{99}
%
\bibitem{ltoutenc}
  Johannes Braams, David Carlisle, Alan Jeffrey, Frank Mittelbach, 
  Chris Rowley, Rainer Sch\"opf: \texttt{ltoutenc.dtx} (part of the 
  \LaTeXe\ base distribution).
%
\bibitem{fontinst}
  Alan Jeffrey, Rowland McDonnell (manual), Sebastian Rahtz, 
  Ulrik Vieth: \emph{The fontinst utility} (v\,1.8), 
  \texttt{fontinst.dtx}, in CTAN at \texttt{ftp:/\slash 
  ftp.tex.ac.uk\slash tex-archive\slash fonts\slash utilities\slash 
  fontinst\slash}\textellipsis
%
\bibitem{fntguide}
  \LaTeX3 Project Team: \emph{\LaTeXe\ font selection},
  \texttt{fntguide.tex} (part of the \LaTeXe\ base distribution).
%
\bibitem{encguide}
  Frank Mittelbach [et al. ?]: \texttt{encguide.tex}. To appear as 
  part of the \LaTeXe\ base distribution. Sometime. Or at least, that 
  is the intention.
%
\end{thebibliography}


\end{document}