11

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:

missing em dashes

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?

  • Welcome to TeX.SE! Please what is the question here? – Kurt Feb 28 at 6:33
  • @Kurt The question is "em dash ligatures that aren't followed by spaces aren't rendered as em dashes, and how can I fix it?" – Alan Munn Feb 28 at 6:38
  • 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
  • 1
    @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
  • 1
    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
13

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}

output of code

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

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}

enter image description here

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}

enter image description here

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.