# Fix encoding for ligatures of fonts in XeTeX / LuaLaTeX (specifically for Minion Pro) [closed]

EDIT 7/6/2018: The problem described below apparently was a bug in Apple's PDFKit and it seems that as of macOS High Sierra 10.13.5 they finally fixed it!

Ligatures in the MWE below are not encoded properly when compiling with LuaLaTeX or XeLaTeX using TeXShop on the Mac. Copying "The difference" from the pdf to a text editor renders "e di erence".

I am aware this has been asked before (see here and links therein), but none of these posts provide a solution that works with XeLaTeX/LuaLaTeX and the Minion Pro font (which I am interested in here).

\documentclass{article}
\usepackage{fontspec}
\setmainfont[Ligatures=TeX]{Minion Pro}
\begin{document}
The difference.
\end{document}


Can anyone think of a solution similar to this but working with XeTeX/LuaTeX?

From the discussion in the comments to this question it seems that it's either a problem with XeTeX or with the font (Linux Libertine in that post). Since the Minion Pro font is an Adobe font I assume the encoding should be ok (?) ... and since both LuaLaTeX and XeTeX give me the same result I assume the problem must be elsewhere (?).

EDIT

I'm stunned that no one seems to be able to reproduce this.

I don't know the exact source of the problem, but I there seem to be multiple issues. It doesn't seem to be primarily a LaTeX issue, but whether I compile with XeLaTeX or LuaLaTeX does make a difference with some fonts and PDF readers. I have no idea where to look for the problem. It could be the fonts themselves, the PDF Reader, or something with my system's font handling—and likely all of the above.

Apparently there is a bug in recent versions of the PDFKit engine on the Mac. Some ligatures of some fonts don't seem to be recognized with viewers based on PDFKit, like Preview, TeXShop, Skim, etc. Viewing with Adobe Acrobat seems to work fine.

Now that can't be the only problem, since (a) no one here seems to be able to reproduce it and (b) there seem to be other issues with some fonts themselves.

I tested the following with a number of other fonts and the full set of ligatures using this:
fluffier soufflé fisticuffs fb fh ffh fj ffj fk ffk ft fft tt Qu Th ch ck ct

I tested the following fonts:
Others on my system: Iowan Old Style, Baskerville, Brill, Quivira, Junicode, Gentium.
LaTeX (only with Lua): Linux Libertine O and EB Garamond

I first compiled a PDF with XeLaTeX then one with Lua. And then I opened each PDF in both Preview and Acrobat and copied the text into a text editor.

Here is what I got:

Compiled with XeLaTeX: The fonts Iowan Old Style, Brill, Quivira, Baskerville all ligatures are rendered correctly with both PDFKit and Acrobat. Opening in Preview (PDFKit), Junicode is missing fj ft fft and none the Adobe fonts shows any of the ligatures, neither does Gentium.
Opening in Acrobat all ligatures are fine for all fonts except for Minion, Garamond Premier and Junicode: For Minion and Garamond Premier the following four ligatures ffi, ffh, ffj, and ffk show up as question mark boxes 􀄎 and ffl is encoded as ffh (which is strange since they are Adobe's own fonts).

Compiled with LuaLaTeX: Here opening in Acrobat all fonts provide the correct output.
However, with PDFKit, the results are worse: Now, in addition to the Adobe fonts and Gentium, Iowan Old Style also doesn't produce any output for ligatures. The only ones working are Brill, Quivira, and Baskerville.

Of the LaTeX fonts (which I couldn't figure out how to test in XeTeX) EB Garamond works (although it doesn't have the Th ligature that the Adobe version has), but Linux Libertine doesn't render any of the ligatures.

As there are so many problems with so many different fonts, I doubt that it's just a corrupted font file — since then most of my fonts would be corrupt.

Any help on where I could look for this issue?
If I could be sure it's only my particular installation of the OS I'd already be happy, as long as TeX is unaffected – I don't want to produce PDFs with corrupt font encodings.

## closed as off-topic by cfr, Phelype Oleinik, Mensch, Thérèse, Stefan PinnowJul 7 '18 at 6:15

• This question does not fall within the scope of TeX, LaTeX or related typesetting systems as defined in the help center.
If this question can be reworded to fit the rules in the help center, please edit the question.

• I can’t reproduce the problem. – Thérèse May 2 '16 at 11:54
• Neither can I; can you add some information about your TeX distribution? What PDF viewer are you using? – egreg May 2 '16 at 12:07
• Perhaps it’s a buggy version of the font, especially since the problem appears to be independent of the engine. Please run luaotfload-tool --list='*' | grep -i minionpro-regular, what version string does it report? – Philipp Gesang May 2 '16 at 19:42
• I can reproduce it. Taking the MWE and compiling from the shell on macOS 10.12.1 with Minion Pro v2.108, a fully updated TeXLive 2016 as now with XeLaTeX 3.14159265-2.6-0.99996 and LuaLaTeX 0.95.0. The resulting pdf-files does not work in Preview 9.0 (909.6), Safari 10.0.1 (12602.2.14.0.7) or Skim 1.4.24 (98) (all based on PDFKit). It is however working in Chrome 54.0.2840.98 build-in pdf viewer. There is a Skim bug report saying that it is a PDFkit problem: sourceforge.net/p/skim-app/bugs/1087 – neic Nov 24 '16 at 14:42
• I'm voting to close this question as off-topic because it was due to a bug in Apple's PDF kit, now fixed. – cfr Jul 6 '18 at 22:53