3

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 soufflé fisticuffs fb fh ffh fj ffj fk ffk ft fft tt Qu Th ch ck ct

I tested the following fonts:
From Adobe: Adobe Jenson, Minion, Garamond, and Brioso.
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.

jan
  • 2,236
  • I can’t reproduce the problem. – Thérèse May 02 '16 at 11:54
  • Neither can I; can you add some information about your TeX distribution? What PDF viewer are you using? – egreg May 02 '16 at 12:07
  • Hmm, that's really weird. Latest TexLive (MacTeX). All updates current. Compiling with TeXShop on the Mac. I copy it directly out of the PDF viewer of TeXShop. But with Preview it's the same. – jan May 02 '16 at 12:25
  • 1
    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 02 '16 at 19:42
  • For me, copy-paste works fine for XeLaTeX and LuaLaTeX. However, the PDF output is horrible with XeLaTeX, although it is fine with LuaLaTeX. In effect, the font is unusable with the former but would be fine with the latter. But this is presumably a different problem with Minion and/or XeLaTeX from the one asked about here, which I can't reproduce either. – cfr May 03 '16 at 03:12
  • Is anyone of you using TeXShop on a Mac? After some more testing it seems related to this bug. Adobe Acrobat recognizes the PDF text without problem. It seems that TeXShop's PDF viewer is based on the Mac PDFKit and that's what's causing the problem. The weird thing is, though, that not all fonts are rendered incorrectly. It seems to be mainly Adobe fonts (which also have many ligatures). Some bizarre Adobe - Apple incompatibility? – jan May 03 '16 at 03:56
  • Using TeXshop and MacTeX2015 (all updates applied, LateX2e format version 2016/03/31) on MacOSX 10.11.4 "El Capitan", I experience no problems under either LuaLateX or XeLaTeX. – Mico May 03 '16 at 05:21
  • @Mico I'm clueless as to what could be causing the problem then. Would you mind testing with ffi, ffl, ffh? And maybe other fonts? I get the same behavior with the TeX live preinstalled Linux Libertine O. With EB Garamond it seems fine. Maybe it's indeed a corrupted version of my fonts? Or some other problem on my system? Although now I have no clue anymore where I should start looking. – jan May 03 '16 at 05:32
  • @jan - No problems on my system with ffi, ffl, ffh either. :-( Minion Pro should be a system font on a MacOSX system. FWIW, on my system, the file /Library/Fonts/MinionPro-Regular.otf is dated 5 Feb 2007 and has a size of 205608 bytes. – Mico May 03 '16 at 05:36
  • @Mico My MinionPro-Regular.otf is dated 1 Nov 2007 and has 235436 bytes. Could that be the problem? – jan May 03 '16 at 05:42
  • It could -- I have no way of telling for sure, though. – Mico May 03 '16 at 05:57
  • @Mico May I ask you to test with this version? To see if we can identify the problem? – jan May 03 '16 at 06:10
  • Is it possible that the issue is MacOS Preview, since the ligatures seem to copy just fine in Adobe Reader? – bishopcranmer Nov 06 '16 at 04:46
  • @bishopcranmer Yes, technically it's not Preview but PDFKit which is the underlying engine for displaying PDFs on MacOS so that amounts to the same thing. But it also seems that how the PDF is created makes a difference. And some people as per the comments above seem to not have that problem even on a Mac. I still haven't figured out how to make a PDF "Mac safe" so that ligatures will always be copied correctly no matter what the platform. – jan Nov 08 '16 at 03:25
  • 1
    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: https://sourceforge.net/p/skim-app/bugs/1087/ – neic Nov 24 '16 at 14:42
  • @jan Did you find a solution for the problem? I still haven't figured out how to make a PDF "Mac safe" so that ligatures will always be copied correctly no matter what the platform. – Victor Mar 30 '17 at 14:39
  • @Victor No, unfortunately not. Unless Apple fixes this odd behavior in PDFKit, I doubt there's anything that can be done about it. – jan Mar 31 '17 at 15:16
  • 5
    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 06 '18 at 22:53

0 Answers0