doc 4

git-svn-id: svn://tug.org/texlive/trunk@80 c570f23f-e606-0410-a88d-b1316a301751

2 files changed, 1725 insertions, 0 deletions

diff --git a/Master/texmf-dist/doc/latex/relenc/reldemo.tex b/Master/texmf-dist/doc/latex/relenc/reldemo.tex
new file mode 100644
index 00000000000..c918a900308
--- /dev/null
+++ b/Master/texmf-dist/doc/latex/relenc/reldemo.tex
@@ -0,0 +1,440 @@
+\documentclass{article}
+
+\usepackage{relenc}
+\usepackage[T1R,OT1]{fontenc}
+ % ot1enc.def is inputed since I still want OT1 to be the default 
+ % encoding in this document.
+
+
+\makeatletter
+
+% General font parameters:
+\newdimen\demofontem \newdimen\demofontex \newskip\demofontspace
+
+ % This macro sets the font parameters for the current font, using 
+ % default values if the \fontdimen values are too strange (probably 
+ % because the font is a raw font not meant for typesetting).
+\def\setfontparams{%
+%    \sbox{\letterbox}{a}%  Make sure the font really is loaded (?)
+   \ifdim 0.1pt<\fontdimen6\font  % Quad width
+      \setlength\demofontem{1em}%
+   \else
+      \demofontem=\f@size\p@
+   \fi
+   \ifdim0.1pt<\fontdimen5\font  % x-height
+      \setlength\demofontex{1ex}%
+   \else
+      \demofontex=0.4\demofontem
+   \fi
+   \ifdim0.1pt<\fontdimen2\font  % Interword space natural width
+      \setlength\demofontspace{\fontdimen2\font plus\fontdimen3\font
+         minus\fontdimen4\font
+      }%
+   \else
+      \setlength\demofontspace{0.2222\demofontem
+         plus0.1111\demofontem minus0.05555\demofontem
+      }%
+   \fi
+}
+
+% Generating the font table:
+\newcount\slotnbr \newcount\rownbr \newcount\colnbr
+\newdimen\thinlinesize \newdimen\thicklinesize \newdimen\squarewidth
+\newsavebox\letterbox
+\setlength\thinlinesize{0.24pt}
+\setlength\thicklinesize{0.75pt}
+\mathchardef\tablecolumns=16
+
+\def\linespreadstrut{\vrule height2.5\demofontex depth1.5\demofontex width0pt}
+\def\emptyrowrule{\rlap{\vrule height2.5\demofontex depth-2\demofontex 
+   width\thinlinesize}\vrule height-1\demofontex depth1.5\demofontex 
+   width\thinlinesize
+}
+\def\stdtext#1{{\normalfont#1}}
+\def\tttext#1{{\normalfont\ttfamily#1}}
+  % Used on things that should not be typeset in the demo font.
+
+\def\nextslot{%
+   \sbox{\letterbox}{\unhbox\letterbox
+      \hb@xt@\squarewidth{\hss\linespreadstrut\char\slotnbr\hss}%
+      \vrule width\thinlinesize
+   }%
+   \global\advance \slotnbr \@ne
+}
+\def\rowheading{%
+   \hb@xt@1.5\demofontem{\hss
+      \linespreadstrut
+      \stdtext{\strut\the\slotnbr}\hskip0.2\demofontem
+   }%
+}
+\def\makebodyrow{\colnbr=\z@
+   \sbox{\letterbox}{%
+      \rowheading
+      \vrule width\thicklinesize
+   }%
+   \loop
+      \nextslot
+      \advance \colnbr \@ne
+   \ifnum \tablecolumns>\colnbr \repeat
+   \box\letterbox
+}
+\def\emptybodyrow{%
+   \hbox{%
+      \sbox\letterbox{%
+         \colnbr=\z@
+         \loop
+            \hskip\squarewidth
+            \advance \colnbr \@ne
+         \ifnum \tablecolumns>\colnbr
+            \vrule width\thinlinesize height\demofontex depth\z@
+         \repeat
+      }%
+      \tabskip=\z@skip
+      \valign{\vfil##\vfil\cr
+         \rowheading\cr
+         \noalign{\vrule width\thicklinesize}%
+         \relax\offinterlineskip
+         \halign{\hfil##\hfil\cr \copy\letterbox\cr
+            \noalign{\vfill}\stdtext{\strut These slots are empty}\cr
+            \noalign{\vfill}\box\letterbox\cr
+         }\cr
+         \noalign{\vrule width\thinlinesize}%
+         \cr
+      }%
+   }%
+   \global\advance \slotnbr \tablecolumns
+}
+\def\bodyrow{%
+   \setbox\letterbox=\hbox{%
+      \colnbr=\z@
+      \penalty\@ne
+      \loop
+         \char\slotnbr
+         \advance \slotnbr \@ne %Note: Non-global advancement
+         \advance \colnbr \@ne
+      \ifnum \tablecolumns>\colnbr \repeat
+      \ifnum \@ne=\lastpenalty % Are all characters in the row missing?
+         \def\next{iffalse}% Yes
+      \else
+         \def\next{iftrue}% No
+      \fi
+      \expandafter
+   }%
+   \csname\next\endcsname % Will be either \iftrue or \iffalse.
+      \makebodyrow
+   \else
+      \emptybodyrow
+   \fi
+   \hrule height\thinlinesize
+}
+\def\toprow{%
+   \colnbr=\z@
+   \sbox{\letterbox}{%
+      \hb@xt@1.5\demofontem{\hss\linespreadstrut}%
+      \vrule width\thicklinesize
+   }%
+   \loop
+      \sbox{\letterbox}{%
+         \unhbox\letterbox
+         \hb@xt@\squarewidth{\hss\linespreadstrut
+            \stdtext{\the\colnbr}\hss
+         }%
+         \vrule width\thinlinesize
+      }%
+      \advance \colnbr \@ne
+   \ifnum \tablecolumns>\colnbr \repeat
+   \box\letterbox
+   \hrule height\thicklinesize
+}
+\def\MakeFontTable{%
+   \medskip
+   \setlength{\squarewidth}{1.6\demofontem}%
+   \hb@xt@\linewidth{\hss
+      \vbox{%
+         \tracinglostchars=\z@
+         \global\slotnbr=\z@
+         \toprow
+         \rownbr=\z@
+         \loop
+           \begingroup\bodyrow\endgroup
+           \advance \rownbr \@ne
+         \ifnum 16>\rownbr \repeat
+      }%
+      \hss
+   }
+   \par\bigskip
+}
+
+
+% Lists of symbols:
+
+% A list of symbols consists of a sequence of \do{<symbol>} units, 
+% where <symbol> can be one (or possibly several) of the following: 
+% a category 11 or 12 token, such as `a' or `!'; a \chardef control 
+% sequence such as `\&'; a LaTeX symbol command such as \textsterling. 
+% (You can actually use a lot of stupid things in a <symbol> and still 
+% have it work, but don't be surprised if it won't for something 
+% that does not fit the above description.)
+
+\newcommand\AddToList[2]{%
+   \relax % Can't hurt.
+   \ifx\relax#1
+      \def#1{\do{#2}}%
+   \else
+      \expandafter\def \expandafter#1\expandafter{#1\do{#2}}%
+   \fi
+}
+
+\def\OTOneBasicLettersListUC{%
+   \do{A}\do{B}\do{C}\do{D}\do{E}\do{F}\do{G}\do{H}\do{I}\do{J}\do{K}%
+   \do{L}\do{M}\do{N}\do{O}\do{P}\do{Q}\do{R}\do{S}\do{T}\do{U}\do{V}%
+   \do{W}\do{X}\do{Y}\do{Z}\do{\AE}\do{\OE}\do{\O}%
+}
+\let\TOneBasicLettersListUC=\OTOneBasicLettersListUC
+\AddToList\TOneBasicLettersListUC{\DH}
+\AddToList\TOneBasicLettersListUC{\DJ}
+\AddToList\TOneBasicLettersListUC{\L}
+\AddToList\TOneBasicLettersListUC{\NG}
+\AddToList\TOneBasicLettersListUC{\SS}
+\AddToList\TOneBasicLettersListUC{\TH}
+
+\def\OTOneBasicLettersListLC{%
+   \do{a}\do{b}\do{c}\do{d}\do{e}\do{f}\do{g}\do{h}\do{i}\do{j}\do{k}%
+   \do{l}\do{m}\do{n}\do{o}\do{p}\do{q}\do{r}\do{s}\do{t}\do{u}\do{v}%
+   \do{w}\do{x}\do{y}\do{z}\do{\ae}\do{\i}\do{\j}\do{\oe}\do{\o}%
+   \do{\ss}%
+}
+\let\TOneBasicLettersListLC=\OTOneBasicLettersListLC
+\AddToList\TOneBasicLettersListLC{\dh}
+\AddToList\TOneBasicLettersListLC{\dj}
+\AddToList\TOneBasicLettersListLC{\l}
+\AddToList\TOneBasicLettersListLC{\ng}
+\AddToList\TOneBasicLettersListLC{\th}
+
+\def\OTOneAccentsList{%
+   \do{\@firstofone}% This is a "no accent" accent.
+   \do{\`}\do{\'}\do{\^}\do{\~}\do{\"}\do{\H}\do{\r}%
+   \do{\v}\do{\u}\do{\=}\do{\.}\do{\b}\do{\c}\do{\d}%
+} 
+\let\TOneAccentsList=\OTOneAccentsList
+\AddToList\TOneAccentsList{\k}
+
+\newcommand\ApplyListToList[3]{%
+  % The first list here, which is given as #1, should really be a list 
+  % of one-parameter commands. The second list, which should be given 
+  % as #2, should be a normal list of symbols. Each command of the first 
+  % list is applied to the symbols in the second list. #3 is inserted 
+  % after every such application.
+   \def\do##1{{\def\do####1{##1{####1}#3}#2}}%
+   #1%
+}
+
+\newcommand\MakeTOneAccentedTable{%
+   \medskip
+   \ApplyListToList{\TOneAccentsList}{%
+      \TOneBasicLettersListLC\par\TOneBasicLettersListUC\par
+   }{\-}%
+   \bigskip
+}
+\newcommand\MakeOTOneAccentedTable{%
+   \medskip
+   \ApplyListToList{\OTOneAccentsList}{%
+      \OTOneBasicLettersListLC\par\OTOneBasicLettersListUC\par
+   }{\-}%
+   \bigskip
+}
+
+
+\let\TOneLeftGlyphsListLC=\TOneBasicLettersListLC
+\AddToList\TOneLeftGlyphsListLC{ff}
+
+\let\OTOneLeftGlyphsListLC=\OTOneBasicLettersListLC
+\AddToList\OTOneLeftGlyphsListLC{ff}
+
+\newcommand\ListTimesList[3]{%
+  % This "generates" the Cartesian product of two lists: For each \do in 
+  % the first list a copy of the second list appears, and for each \do 
+  % in the second list the current element from the first list is 
+  % inserted. As with \ApplyListToList, #3 is inserted at the end of each 
+  % \do from the second list.
+   \def\do##1{{\def\do####1{##1####1#3}#2}}%
+   #1%
+}
+
+\newcommand\MakeTOnePairsTable{%
+   \medskip
+   \ListTimesList{\TOneLeftGlyphsListLC}{\TOneBasicLettersListLC\par}{%
+      \hskip\demofontspace
+   }%
+   \smallskip
+   \ListTimesList{\TOneBasicLettersListUC}{\TOneBasicLettersListLC\par}{%
+      \hskip\demofontspace
+   }%
+   \smallskip
+   \ListTimesList{\TOneBasicLettersListUC}{\TOneBasicLettersListUC\par}{%
+      \hskip\demofontspace
+   }%
+   \bigskip
+}   
+
+\newcommand\MakeOTOnePairsTable{%
+   \medskip
+   \ListTimesList{\OTOneLeftGlyphsListLC}{\OTOneBasicLettersListLC\par}{%
+      \hskip\demofontspace
+   }%
+   \smallskip
+   \ListTimesList{\OTOneBasicLettersListUC}{\OTOneBasicLettersListLC\par}{%
+      \hskip\demofontspace
+   }%
+   \smallskip
+   \ListTimesList{\OTOneBasicLettersListUC}{\OTOneBasicLettersListUC\par}{%
+      \hskip\demofontspace
+   }%
+   \bigskip
+}   
+
+
+\def\OTOneSymbolsList{\do{\textemdash}\do{\textendash}%
+   \do{\textexclamdown}\do{\textquestiondown}\do{\textquotedblleft}%
+   \do{\textquotedblright}\do{\textquoteleft}\do{\textquoteright}%
+   \do{\textdollar}\do{\textsterling}%
+}
+\let\TOneSymbolsList=\OTOneSymbolsList
+\AddToList\TOneSymbolsList{\guillemotleft}
+\AddToList\TOneSymbolsList{\guillemotright}
+\AddToList\TOneSymbolsList{\guilsinglleft}
+\AddToList\TOneSymbolsList{\guilsinglright}
+\AddToList\TOneSymbolsList{\quotedblbase}
+\AddToList\TOneSymbolsList{\quotesinglbase}
+\AddToList\TOneSymbolsList{\textasciicircum}
+\AddToList\TOneSymbolsList{\textasciitilde}
+\AddToList\TOneSymbolsList{\textbackslash}
+\AddToList\TOneSymbolsList{\textbar}
+\AddToList\TOneSymbolsList{\textbraceleft}
+\AddToList\TOneSymbolsList{\textbraceright}
+\AddToList\TOneSymbolsList{\textcompwordmark}
+\AddToList\TOneSymbolsList{\textgreater}
+\AddToList\TOneSymbolsList{\textless}
+\AddToList\TOneSymbolsList{\textperthousand}
+\AddToList\TOneSymbolsList{\textpertenthousand}
+\AddToList\TOneSymbolsList{\textquotedbl}
+\AddToList\TOneSymbolsList{\textsection}
+\AddToList\TOneSymbolsList{\textunderscore}
+\AddToList\TOneSymbolsList{\textvisiblespace}
+
+
+\newcommand\MakeOTOneSymbolsTable{\MakeSymbolsTable\OTOneSymbolsList}
+\newcommand\MakeTOneSymbolsTable{\MakeSymbolsTable\TOneSymbolsList}
+\newcommand\MakeSymbolsTable[1]{%
+   \begingroup
+      \def\do##1{\tttext{\string##1}&##1\cr}%
+      \tabskip=\hideskip
+      \halign to\linewidth{##\hfil \tabskip=\ht\strutbox&
+         \hfil##\hfil \tabskip=\hideskip\cr
+         \stdtext{\TeX\ code}&\stdtext{Symbol}\cr
+         #1%
+      }%
+   \endgroup
+   \par\bigskip
+}
+
+
+% Combining it all
+
+\newcommand\DemoTOneLaTeXFont[4]{%
+   \vfil\penalty0\vfilneg
+   \markright{\stdtext{Demo of \LaTeX\ font \ttfamily #1/#2/#3/#4}\hss}%
+   \begingroup
+      \usefont{#1}{#2}{#3}{#4}%
+      \setfontparams
+      \noindent\stdtext{\textbf{Font table}}\par
+      \MakeFontTable
+      \noindent\stdtext{\textbf{Accents/letters table}}\par
+      \MakeTOneAccentedTable
+      \noindent\stdtext{\textbf{Pairs tables}}\par
+      \MakeTOnePairsTable
+      \noindent\stdtext{\textbf{Symbols table}}\par
+      \MakeTOneSymbolsTable
+      \ifx \TOneDemoText\@undefined \else
+         \medskip\TOneDemoText\medskip
+      \fi
+   \endgroup
+}
+\newcommand\DemoOTOneLaTeXFont[4]{
+   \vfil\penalty0\vnegfil
+   \markright{\stdtext{Demo of \LaTeX\ font \ttfamily #1/#2/#3/#4}\hss}%
+   \begingroup
+      \usefont{#1}{#2}{#3}{#4}%
+      \setfontparams
+      \noindent\stdtext{\textbf{Font table}}\par
+      \MakeFontTable
+      \noindent\stdtext{\textbf{Accents/letters table}}\par
+      \MakeOTOneAccentedTable
+      \noindent\stdtext{\textbf{Pairs tables}}\par
+      \MakeOTOnePairsTable
+      \noindent\stdtext{\textbf{Symbols table}}\par
+      \MakeOTOneSymbolsTable
+      \ifx \OTOneDemoText\@undefined \else
+         \medskip\OTOneDemoText\medskip
+      \fi
+   \endgroup
+}
+\newcommand\DemoRawTeXFont[1]{\begingroup
+   \font\demofont=#1\relax
+   \demofont
+   \setfontparams
+   \MakeFontTable
+   \endgroup
+}
+
+\makeatother
+
+\pagestyle{myheadings}
+
+\begin{document}
+\errorcontextlines=999\relax
+
+You should at least read Appendix C of the package documentation 
+before viewing this example, but if you prefer not to then I must at 
+least point out that the fonts in the \texttt{zcm} family are mainly 
+\texttt{cmr10} that has been completed with various ``faked'' 
+characters. As a result, many of the characters does not look very 
+good and some look downright ugly, but there is no particular harm in 
+that since the \texttt{zcm} fonts are not intended to be used in any 
+serious typesetting anyway.
+
+The first font in the \texttt{zcm} family---the \texttt{T1R}\slash 
+\texttt{zcm}\slash\texttt{m}\slash\texttt{n} font---has a coding scheme 
+identical to that used for fonts in the \texttt{T1} encoding. It 
+shows the default setup for the \texttt{T1R} encoding.
+
+The font table shows the contents of each slot. The accents/letters 
+table shows the result of the non-accented letters as they are and 
+their appearence after having been subjected to each accenting command 
+in turn. The pairs tables shows all the ligatures and the symbols 
+table finally shows the symbol commands and their effect.
+
+\bigskip
+\DemoTOneLaTeXFont{T1R}{zcm}{m}{n}
+
+The second font in the \texttt{zcm} family---the \texttt{T1R}\slash 
+\texttt{zcm}\slash\texttt{m}\slash\texttt{a} font---has four extra 
+ligatures: ct, fj, ffj, and st. These appear in the font table at 
+positions 128, 130, 131, and 161. Despite the fact that four of the 
+characaters that were used for making accented letters in the 
+\texttt{T1R}\slash\texttt{zcm}\slash\texttt{m}\slash\texttt{n} font are 
+missing however, the accents/letters table for the \texttt{T1R}\slash
+\texttt{zcm}\slash\texttt{m}\slash\texttt{a} font display the same accented 
+letters as the ditto table for the \texttt{T1R}\slash\texttt{zcm}\slash
+\texttt{m}\slash\texttt{n} font did. Under the \texttt{T1} encoding, 
+the result would instead have been that some of the accented letters 
+would incorrectly have been replaced by the ligatures.
+
+The pairs tables show that the four extra ligatures work as ligatures 
+and the symbols table looks exactly as for the \texttt{T1R}\slash
+\texttt{zcm}\slash\texttt{m}\slash\texttt{n} font.
+
+\bigskip
+\DemoTOneLaTeXFont{T1R}{zcm}{m}{a}
+
+\end{document}
diff --git a/Master/texmf-dist/doc/latex/relenc/relenc.tex b/Master/texmf-dist/doc/latex/relenc/relenc.tex
new file mode 100644
index 00000000000..4fda9e8d641
--- /dev/null
+++ b/Master/texmf-dist/doc/latex/relenc/relenc.tex
@@ -0,0 +1,1285 @@
+\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}