LuaTeX and em dashes

LuaLaTeX is not inserting em dashes unless there is space around the triple dash. It works fine when using a unicode em dash, or explicitly using the \textemdash macro.

Here is a MWE:

\documentclass{article}

\begin{document}

\begin{enumerate}
\item en--dash
\item em---dash
\item em --- dash space
\end{enumerate}
\begin{enumerate}
\item en–dash unicode
\item em—dash unicode
\item em — dash space unicode
\end{enumerate}
\begin{enumerate}
\item en\textendash{}dash macro
\item em\textemdash{}dash macro
\item em \textemdash{} dash space macro
\end{enumerate}

\end{document}


Which produces:

Compiled using LuaTeX, Version 1.07.0 (TeX Live 2018)

The question is:

I would like to know why em dash ligatures without surrounding spaces are not rendered as em dashes in the PDF output. It seems like a bug to me. how can I fix it?

• See also github.com/u-fischer/luaotfload/issues/44 and the discussion starting with mailman.ntg.nl/pipermail/ntg-context/2019/094208.html at the ConTeXt mailing list. – moewe Feb 28 at 6:46
• @AndyN Yesterday I was going to ask this exact same question before I found the mailing list moewe pointed you to. Another funny combination is \item em---dash---twice. Apparently when a word is surrounded by two em-dashes, the first one is rendered as an en-dash, while the second shows up normally. – Phelype Oleinik Feb 28 at 11:07
• I added the question at the end of your question, I hope that is okay for you! If not please feel free to do a rollback. – Kurt Mar 1 at 1:11

You can add \automatichyphenmode=1 to your preamble:

\documentclass{article}
\automatichyphenmode=1
\begin{document}

\begin{enumerate}
\item en--dash
\item em---dash
\item em --- dash space
\end{enumerate}
\begin{enumerate}
\item en–dash unicode
\item em—dash unicode
\item em — dash space unicode
\end{enumerate}
\begin{enumerate}
\item en\textendash{}dash macro
\item em\textemdash{}dash macro
\item em \textemdash{} dash space macro
\end{enumerate}

\end{document}


• This fixes the problem. Though I'm still not sure why. – Andy N Feb 28 at 7:00

Update 3/2019

The bug will be resolved with the next luaotfload update

==============================================================

To expand a bit on Alan's answer:

It is imho clearly a bug in the fontloader imported from context (you see the same in context if you set \automatichyphenmode=0). It only happens if the fonts are rendered with the mode=node:

\documentclass{article}

\begin{document}
\font\test={file:lmroman10-regular.otf:mode=node;+tlig}
\test

A---B

\font\test={file:lmroman10-regular.otf:mode=base;+tlig}
\test

A---B
\end{document}


The source of the problem is imho that with \automatichyphenmode=0, luatex has at first to convert the last hyphen to a discretionary to allow a linebreak:

A---B  ---> A--\discretionary{-}{}{-}B


and after the line has been set this has to be converted back again to ---, and this step seems to fail.

The problem has been reported, but it is unclear if it will be fixed.

\automatichyphenmode=1 avoids the problem by not converting the hyphen to a discretionary in a number of cases. So you should be aware of the fact that this suppress line breaking in a number of cases:

\documentclass[parskip=half-]{scrartcl}
\begin{document}

\parbox[t]{1pt}{%
\textbf{0}

\automatichyphenmode=0
A-B

A--B

A---B

-begin

A!-B}
\hspace{2cm}
\parbox[t]{1pt}{\automatichyphenmode=1
\textbf{1}

A-B

A--B

A---B

-begin

A!-B}

\end{document}