# Bug in fontenc (or libertine)?

I am working on a book with aprox. 200+ A5 pages. In the process of migrating from pdflatex to xelatex I noticed some serious layout differences. In an effort to trace down the problem, I came to following MWE for pdflatex.

\documentclass[paper=a5,pagesize,fontsize=13pt]{scrbook}
\usepackage{showframe}
\usepackage[T1]{fontenc}
\usepackage[osf]{libertine}

\begin{document}
Hello, here is some text without a meaning. This text
should show what a printed text will look like at this place.
\end{document}


If

\usepackage[T1]{fontenc}


is in force then the first text line ends with "This text". If commented out it ends with "This text should" also producing an overfull box.

• Why are you loading fontenc with xelatex? Load fontspec. – Johannes_B Feb 17 '15 at 16:32
• Because I am only running pdflatex. Sorry for not stating that clearly. At first I thought it was a xelatex item, but it turned out to be a fontenc/pdflatex problem. – Jack Feb 17 '15 at 16:37
• I still want to use pdflatex when working on the draft because xelatex is so slow. Due to some special things I do I need 4 runs each time. But the differences are very disturbing. – Jack Feb 17 '15 at 16:41
• Fontsize 13pt is quite unusual, there are some warnings about font substitutions ... reduce to 12pt and the output will be (effectively) the same, using fontenc or not, without overfull hbox warnings – user31729 Feb 17 '15 at 16:53
• BTW: If you want to switch between pdflatex and XeLaTeX from time to time, it's a good idea to write one preamble for both using \ifxetex. But maybe you're already did that… – JBantje Feb 17 '15 at 17:55

The difference is due to

OT1:

.\OT1/LinuxLibertineT-TOsF/m/n/13 i
.\OT1/LinuxLibertineT-TOsF/m/n/13 n
.\OT1/LinuxLibertineT-TOsF/m/n/13 g
.\OT1/LinuxLibertineT-TOsF/m/n/13 .
.\glue 3.7921 plus 4.875 minus 0.36096
.\OT1/LinuxLibertineT-TOsF/m/n/13  (ligature Th)
.\OT1/LinuxLibertineT-TOsF/m/n/13 i
.\OT1/LinuxLibertineT-TOsF/m/n/13 s
.\glue 3.25 plus 1.625 minus 1.08289
.\OT1/LinuxLibertineT-TOsF/m/n/13 t
.\OT1/LinuxLibertineT-TOsF/m/n/13 e
.\kern-0.091
.\OT1/LinuxLibertineT-TOsF/m/n/13 x
.\OT1/LinuxLibertineT-TOsF/m/n/13 t


T1:

....\T1/LinuxLibertineT-TOsF/m/n/13 i
....\T1/LinuxLibertineT-TOsF/m/n/13 n
....\T1/LinuxLibertineT-TOsF/m/n/13 g
....\T1/LinuxLibertineT-TOsF/m/n/13 .
....\glue 3.7921 plus 4.875 minus 0.36096
....\T1/LinuxLibertineT-TOsF/m/n/13 T
....\T1/LinuxLibertineT-TOsF/m/n/13 h
....\T1/LinuxLibertineT-TOsF/m/n/13 i
....\T1/LinuxLibertineT-TOsF/m/n/13 s
....\glue 3.25 plus 1.625 minus 1.08289
....\T1/LinuxLibertineT-TOsF/m/n/13 t
....\T1/LinuxLibertineT-TOsF/m/n/13 e
....\kern-0.091
....\T1/LinuxLibertineT-TOsF/m/n/13 x
....\T1/LinuxLibertineT-TOsF/m/n/13 t


that is the OT1 font has a Th ligature that is not present in the T1 font. That's somewhat surprising but not necessarily a bug. After that the word lengths are fractionally different, which is sufficient to cause the paragraph line breaker to take a different path.

You could avoid the ligature like

\documentclass[paper=a5,pagesize,fontsize=13pt]{scrbook}
\usepackage{showframe}
%\usepackage[T1]{fontenc}
\usepackage[osf]{libertine}

%\showoutput

\begin{document}
Hello, here is some text without a meaning. T{}his text
should show what a printed text will look like at this place.
\end{document}

• If using xelatex or lualatex with the opentype libertine, one can use package selnolig to avoid the Th ligature. – musarithmia Feb 17 '15 at 18:33
• The easiest way to avoid the Th-ligature would be to not use the OT1 encoding. – Sverre Feb 18 '15 at 21:23
• @Sverre sure but that was the question really, why does T1 and OT1 produce different setting. It's pretty odd that linux libertine takes a different set of ligatures between T1 and OT1 when considering characters in the OT1 range. It's not a bug, but it is a rather surprising choice in the design of the font metrics – David Carlisle Feb 18 '15 at 21:27
• Well, yes and no. As I read the OP, he simply didn't understand why the versions came out different (it also didn't seem as if he understood that the difference was due to the change of encoding from T1 to OT1). I think the reason the Th-ligature isn't included in the T1 encoding is that there's no room for it there, whereas there is room for it in the OT1 encoding. I personally like this, as it gives me the opportunity to switch to OT1 if I want some extra ligatures that T1 or LY1 don't have. – Sverre Feb 18 '15 at 21:32
• @DavidCarlisle The TH ligature is enabled by default in the OpenType version as well, if compiling with xelatex or lualatex. So the T1 version is the exception, not the rule (though I agree with everyone that the default should be without the TH ligature). – musarithmia Feb 19 '15 at 14:22

You could disable the dreaded Th ligature in OT1 fonts by loading microtype and issuing

\DisableLigatures[T]{encoding=OT1}


but this has the drawback that also kerning against T is disabled, as the following example shows.

\documentclass[paper=a5,pagesize,fontsize=13pt]{scrbook}
\usepackage{showframe}
\usepackage[T1]{fontenc}
\usepackage[osf]{libertine}

\usepackage{microtype}
\DisableLigatures[T]{encoding=OT1}

\begin{document}

\fontencoding{OT1}\selectfont

Hello, here is some text without a meaning. This text
should show what a printed text will look like at this place.

To

\fontencoding{T1}\selectfont

Hello, here is some text without a meaning. This text
should show what a printed text will look like at this place.

To

\end{document}


So there's no real solution to your problem. You could ask the maintainer of the libertine package to add an option for disabling the Th ligature in OT1 encoding (a new set of virtual fonts is needed). In my opinion, this would be a very good feature, as I find the ligature really awful.

• Thanks for all the answers. The book I'm writing is for the greater part in Dutch (and a bit in Sranan, but that does not matter here). So I fear that the solution that work for the MWE won't for my real work. It is more than the 'Th'-ligature. In order to investigate which characters are problematic, I think I need to have the information like the one that David provided in the logfile. I don't know how to do that, but I am sure one of you will reveal it to me. Of course it might blow up my logfile running over 200+ pages. But maybe one can do that selectively. – Jack Feb 17 '15 at 21:55
• But apart from making local work-arounds: isn't there a final way to solve this for once and always? Shouldn't TeX produce the same output, independent from the used engine, where only a few basic packages (i.e fontenc, babel vs fontspec, polyglossia) are different? @David If I select the same encoding (OT1 or T1) for both pdflatex and xelatex, does that solve this issue. Is such a selection at all possible? – Jack Feb 17 '15 at 21:56
• @Jack No, if you use different fonts, the output can certainly be different. – egreg Feb 17 '15 at 21:57
• Well, I do use the same font for both engines. Or did you mean different encodings? – Jack Feb 17 '15 at 22:25
• @Jack No, you're using different fonts: a font, as far as TeX is concerned, is just its metric file. – egreg Feb 17 '15 at 22:26