diff options
Diffstat (limited to 'Master/texmf-dist/doc/latex/relenc')
| -rw-r--r-- | Master/texmf-dist/doc/latex/relenc/reldemo.tex | 440 | ||||
| -rw-r--r-- | Master/texmf-dist/doc/latex/relenc/relenc.tex | 1285 |
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} |