9.1 Introducción

9.1.1 The history of LaTeX’s font selection scheme (NFSS)

When TEX was developed in 1979, only a dozen fonts were set up for use with the program. This situation had not greatly changed five years later, when LaTEX was first released. It was thus quite natural that LaTEX’s font selection scheme followed the plain TEX concept with the addition of size-changing commands that allowed typesetting in ten predefined sizes.

As a result, LaTEX’s font selection was far from general because the font commands were not changing font attributes but exchanged one font with another one. For instance, when, say, the now obsolete command

Since that time low-priced laser printers became available, and simultaneously a large number of font families from PostScript and other font formats appeared. But, unfortunately, because of the LaTEX font selection model, there was no easy and standard method for integrating these new fonts into LaTEX— typesetting with LaTEX meant typesetting in Computer Modern on almost all installations. Of course, individual fonts could be loaded, but they would not work with the size commands nor were they otherwise integrated, so it was extremely complicated to typeset a whole document in a different font family.

This unsatisfactory situation was finally resolved in 1989 with the release of the New Font Selection Scheme (NFSS) [152] written by Frank Mittelbach and Rainer Schöpf, which became widely known after it was successfully used in AMS-LaTEX (see Chapter 11). This system contains a generic concept for varying font attributes individually and for integrating new font families easily into an existing LaTEX system. The concept is based on five attributes that can be defined independently to access different fonts, font characteristics, or font families. To implement it, some of the LaTEX commands were redefined, and some new commands were added.

In 1994 NFSS became the official standard in the then newly released LaTEX 2ε. It has now been in worldwide use for more than thirty years, proving the code to be stable, successful, and most importantly flexible enough to support further advances in font technology and use.

However, in the last decade new requirements appeared that were not easily supported with the original NFSS design and so some extensions in the form of additional support packages appeared.

For pdfTEX two important ones have been mweights by Bob Tennent and fontaxes by Andreas Bühmann and Michael Ummels, both extending the attribute handling of NFSS. Neither package is intended for direct usage but normally used within font support packages, such as those discussed in Chapter 10. In 2020 a large portion of their functionality has been integrated into NFSS so that it is now generally available.

The situation for Unicode engines is different. With the fontspec package by Will Robertson a new frontend for font loading is offered for use in X TE EX and LuaTEX. This frontend allows one to access all kind of font features available with OpenType or TrueType fonts. It then generates the necessary information for NFSS on the fly — thus under the hood NFSS is still the font selection machinery. The package is discussed in detail in Section 9.6.

9.1.2 Input and output handling in TeX systems over the years

When TEX was originally developed in 1979, computers used 7-bits to encode input characters, which allows for a direct representation of a maximum of 128 characters, i.e., Latin upper and lowercase base characters, digits, and a few symbols. Any other character had to be represented in the form of a command or a sequence of commands; e.g., for ß or ^for ˆ, etc.

This certainly allowed inputting text in most Latin-based languages (though al ready a bit inconvenient) where the need for using commands in the input is still restricted to English

infrequent. Already then there were problems; e.g., hyphenation would not work for words containing diacritics. However, that approach clearly failed for languages with a totally different set of characters, where essentially every character would be represented by a command if we assume that the input can represent only ASCII characters directly. For example, the Russian text for “on the next page” (на следующей странице) would have to be written as