\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}