# Reliance on “default” ligatures (!, two hyphens, two straight apostrophes, etc.)

A number of symbols seem to be normally invoked through ligature mechanisms. (Correct me if I'm wrong.) Let's have a look at which ligatures normally exist in encodings/fonts:

• true ligatures (for letters): ff (ﬀ) fi (ﬁ) fl (ﬂ) ffi (ﬃ) ffl (ﬄ)
• other uses of the ligature mechanism (for symbols):  (“) '' (”) ,, („) -- (–) --- (—) ! (¡) ? (¿) << («) >> (»)

(These seem to be the important ones for T1; for OT1 subtract ,, and <</>>. There are other, rare ligatures, and I do not wish to research this exhaustively. Feel free to add information. I am not sure whether this is more of an encoding or a font thing.)

I do not know about the normativity of such "default" ligatures. To what extent are they normative? Where are such conventions fixed? On which ligature conventions can one safely rely on (if any)? For example, is there any reason to always use \textquotedblleft, \textquotedblright, \glqq*, \textendash, \textemdash, \textexclamdown, \textquestiondown, \guillemotleft, \guillemotright instead of the ligature letter sequences in package code?

[* not sure where \glqq works out of the box]

-
This depends on the engine you are using, among other things. I am guessing you are asking in the context of (pdf)LaTeX as opposed to Xe/LuaLaTeX, for example. Note that many of those commands rely on textcomp whereas their ligature equivalents do not. I am not sure what you mean by whether it is 'more of an encoding or a font thing'. It is both, in a way. But the ligatures for (pdf)TeX are in the .tfm files. When you create these, you set them up to do the expected thing. You can make them do other things if you choose. E.g. you can make s at word-end typeset a swash s via a ligature. –  cfr Apr 20 '14 at 0:28
@cfr Yep, asking mainly about (La)TeX, which I use as pdflatex. (I think that's normally assumed unless clarified to the contrary. But it's not surprising that the answer heavily depends on the choice of engine.) As always, information about other members of the TeX-family is welcome. –  Lover of Structure Apr 20 '14 at 1:44

So suppose you run this code through (pdf)LaTeX:

\documentclass{article}
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}

\begin{document}

 (“) '' (”) ,, („) -- (–) --- (—) ! (¡) ? (¿) << («) >> (»)

\textquotedblleft \textquotedblright \textendash \textemdash \textexclamdown \textquestiondown \guillemotleft \guillemotright

\end{document}


fontenc will load t1enc.def which includes the following definitions:

\DeclareTextSymbol{\textquotedblleft}{T1}{16}
\DeclareTextSymbol{\textquotedblright}{T1}{17}
\DeclareTextSymbol{\textendash}{T1}{21}
\DeclareTextSymbol{\textemdash}{T1}{22}
\DeclareTextSymbol{\textexclamdown}{T1}{189}
\DeclareTextSymbol{\textquestiondown}{T1}{190}
\DeclareTextSymbol{\guillemotleft}{T1}{19}
\DeclareTextSymbol{\guillemotright}{T1}{20}


As I understand it, this means that you will get the correct character even if the font has not been set up to support standard T1 ligatures. Provided, that is, the correct glyph is in the correct slot. So if the font for some reason deviates from the standard set by T1 in a different way - it puts ¡ in the wrong slot but sets the standard ligature up to point to that (wrong) slot - then you will get the wrong character whereas the ligature would have got you the right one.

Neither of these is especially likely because any font you are using through (pdf)LaTeX has been set up for TeX. So only if somebody has introduced an error will things go wrong. In the first place, mostly people automate much of the work involved and the tools are generally reliable. In the second, something like this would get reported as a bug and (hopefully) fixed.

The encodings are standardised and the font packages are generally reliable. So both the commands and the ligatures are reliable. Neither is guaranteed but I don't think one is any more subject to error than the other.

# Complications

There are sometimes reasons to 'tweak' or customise a font encoding such as T1. For example, I might adjust the encoding for a particular font in order to accommodate additional characters or ligatures. Now things get complicated. In order to do this, I must use slots assigned by T1 to something else. It is conceivable that somebody might use a slot normally used for one of the characters above for something else and then delete the ligaturing commands pointing to that slot. The only good reason to do that would be if the font didn't provide the glyph and it could not be constructed from other glyphs in the font. In that case, if you could use the slot, you might. Now you might think that in such a case, you should also redefine the relevant \text... command. However, if you do that, you'll overwrite the command for other T1 encoded fonts. So you shouldn't. You'd just have to flag it in the documentation. But notice that in this case things are going to go wrong anyway - since the font doesn't supply the glyph, both the ligature and the command are guaranteed to give the wrong output. There's nothing you can do. At least, there's nothing terribly straightforward you can do, and nothing at all satisfactory.

But almost all fonts supply the particular characters in question so this is largely hypothetical. The exceptions would be specialist fonts such as decorative fonts where you might have a very restricted character set. If you are using those fonts, though, you likely know about it.

In general, getting the expected output is complex. It depends on the active encoding and the font. In the case of (pdf)LaTeX, it depends on the .tfm file and, perhaps, the .vf in addition to the .pfb or truetype font itself. Depending on the font package, there will be multiple encodings involved. For example, you might use a completely different encoding to point to slots in the original font while using T1 or a customised T1 to define the font encoding at the end-user level. Virtual fonts can combine characters from different fonts, specify 'fake' glyphs by telling TeX how to construct them from other glyphs, and so on. If a font does not supply the ff ligature, for example (not uncommon for expert fonts providing small-caps), you can use a virtual font containing instructions for constructing the ff ligature from the f glyph.

When people point out the difference between input and output encoding, they are glossing over the true complexity involved. In many cases, there are additional encodings involved as well.

-
I think there will be a difference when the user disables ligatures. I don't know what all the standard ways are, but writing \DisableLigatures[f]{ encoding = {T1,OT1} } with the microtype package will disable the 5 f-ligatures. (Someone competent told me to also include TS1`, but I don't know why.) When non-letter "ligatures" are disabled, I think there will be a difference between the two ways of creating these symbols. –  Lover of Structure Apr 22 '14 at 7:44
@LoverofStructure True but I'm not sure that makes either method more reliable than the other. After all, if you deliberately disable ligatures then you can't really say that the ligatures are 'unreliable' any more than you can complain that automatic login to your computer is 'unreliable' if it fails to work after you disable it. Indeed, to my mind, the fact that ligatures work only when enabled only increases their reliability. (Similarly, for the 'ff' etc.) –  cfr Apr 22 '14 at 13:24