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 entextendash{}dash macro
item emtextemdash{}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?
luatex tex-core punctuation ligatures
|
show 1 more comment
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 entextendash{}dash macro
item emtextemdash{}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?
luatex tex-core punctuation ligatures
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 isitem 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
|
show 1 more comment
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 entextendash{}dash macro
item emtextemdash{}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?
luatex tex-core punctuation ligatures
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 entextendash{}dash macro
item emtextemdash{}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?
luatex tex-core punctuation ligatures
luatex tex-core punctuation ligatures
edited yesterday
Martin Schröder
12.9k640125
12.9k640125
asked Feb 28 at 6:20
Andy NAndy N
534
534
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 isitem 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
|
show 1 more comment
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 isitem 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
Welcome to TeX.SE! Please what is the question here?
– Kurt
Feb 28 at 6:33
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
@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
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
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
@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
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
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
|
show 1 more comment
2 Answers
2
active
oldest
votes
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 entextendash{}dash macro
item emtextemdash{}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
add a comment |
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}
fonttest={file:lmroman10-regular.otf:mode=node;+tlig}
test
A---B
fonttest={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}
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "85"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2ftex.stackexchange.com%2fquestions%2f477094%2fluatex-and-em-dashes%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
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 entextendash{}dash macro
item emtextemdash{}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
add a comment |
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 entextendash{}dash macro
item emtextemdash{}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
add a comment |
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 entextendash{}dash macro
item emtextemdash{}dash macro
item em textemdash{} dash space macro
end{enumerate}
end{document}
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 entextendash{}dash macro
item emtextemdash{}dash macro
item em textemdash{} dash space macro
end{enumerate}
end{document}
answered Feb 28 at 6:34
Alan MunnAlan Munn
162k28431706
162k28431706
This fixes the problem. Though I'm still not sure why.
– Andy N
Feb 28 at 7:00
add a comment |
This fixes the problem. Though I'm still not sure why.
– Andy N
Feb 28 at 7:00
This fixes the problem. Though I'm still not sure why.
– Andy N
Feb 28 at 7:00
This fixes the problem. Though I'm still not sure why.
– Andy N
Feb 28 at 7:00
add a comment |
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}
fonttest={file:lmroman10-regular.otf:mode=node;+tlig}
test
A---B
fonttest={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}
add a comment |
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}
fonttest={file:lmroman10-regular.otf:mode=node;+tlig}
test
A---B
fonttest={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}
add a comment |
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}
fonttest={file:lmroman10-regular.otf:mode=node;+tlig}
test
A---B
fonttest={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}
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}
fonttest={file:lmroman10-regular.otf:mode=node;+tlig}
test
A---B
fonttest={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}
answered Feb 28 at 9:32
Ulrike FischerUlrike Fischer
194k8302688
194k8302688
add a comment |
add a comment |
Thanks for contributing an answer to TeX - LaTeX Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2ftex.stackexchange.com%2fquestions%2f477094%2fluatex-and-em-dashes%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
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