LuaTex and em dasheslualatex and line breaks after em-dashesIs direct utf8 input of combining diacritics in...
Why do neural networks need so many training examples to perform?
Increment each digit in a number to form a new number
kill -0 <PID> は何をするのでしょうか?
Early credit roll before the end of the film
Why did the villain in the first Men in Black movie care about Earth's Cockroaches?
Removing disk while game is suspended
When can a QA tester start his job?
Quickly creating a sparse array
Can we harness gravitational potential energy?
Why did Democrats in the Senate oppose the Born-Alive Abortion Survivors Protection Act (2019 S.130)?
What incentives do banks have to gather up loans into pools (backed by Ginnie Mae)and selling them?
A curious equality of integrals involving the prime counting function?
If I delete my router's history can my ISP still provide it to my parents?
Can I write a book of my D&D game?
Can a hotel cancel a confirmed reservation?
What is the wife of a henpecked husband called?
Cookies - Should the toggles be on?
How much mayhem could I cause as a sentient fish?
Why publish a research paper when a blog post or a lecture slide can have more citation count than a journal paper?
Non-Cancer terminal illness that can affect young (age 10-13) girls?
How can my powered armor quickly replace its ceramic plates?
Why are the books in the Game of Thrones citadel library shelved spine inwards?
What is the purpose of easy combat scenarios that don't need resource expenditure?
Is using an 'empty' metaphor considered bad style?
LuaTex and em dashes
lualatex and line breaks after em-dashesIs direct utf8 input of combining diacritics in math mode possible with lualatex?Weird permissions problem with TeX Live 2013, Ubuntu 13.04, LuaTeX and problem fontsDisplay ' apostropheLuatex ligatures after newpageMakeidx, Subentries and dashesTypesetting an M-dash at either end of a source line without spaces around itIncorrect LuaTeX ligaturesRunning bashful on WindowsH{u} and H{o} do not appear in the lualatex output PDF
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)
luatex tex-core punctuation ligatures
New contributor
add a 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)
luatex tex-core punctuation ligatures
New contributor
Welcome to TeX.SE! Please what is the question here?
– Kurt
3 hours ago
@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
3 hours ago
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
3 hours ago
Apologies @Kurt, I did not phrase my post as a question. As Alan suggested, I would like to know why em dash ligatures with surrounding spaces are not rendered as em dashes in the PDF output. It seems like a bug to me.
– Andy N
3 hours ago
add a 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)
luatex tex-core punctuation ligatures
New contributor
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)
luatex tex-core punctuation ligatures
luatex tex-core punctuation ligatures
New contributor
New contributor
New contributor
asked 3 hours ago
Andy NAndy N
82
82
New contributor
New contributor
Welcome to TeX.SE! Please what is the question here?
– Kurt
3 hours ago
@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
3 hours ago
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
3 hours ago
Apologies @Kurt, I did not phrase my post as a question. As Alan suggested, I would like to know why em dash ligatures with surrounding spaces are not rendered as em dashes in the PDF output. It seems like a bug to me.
– Andy N
3 hours ago
add a comment |
Welcome to TeX.SE! Please what is the question here?
– Kurt
3 hours ago
@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
3 hours ago
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
3 hours ago
Apologies @Kurt, I did not phrase my post as a question. As Alan suggested, I would like to know why em dash ligatures with surrounding spaces are not rendered as em dashes in the PDF output. It seems like a bug to me.
– Andy N
3 hours ago
Welcome to TeX.SE! Please what is the question here?
– Kurt
3 hours ago
Welcome to TeX.SE! Please what is the question here?
– Kurt
3 hours ago
@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
3 hours ago
@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
3 hours ago
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
3 hours ago
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
3 hours ago
Apologies @Kurt, I did not phrase my post as a question. As Alan suggested, I would like to know why em dash ligatures with surrounding spaces are not rendered as em dashes in the PDF output. It seems like a bug to me.
– Andy N
3 hours ago
Apologies @Kurt, I did not phrase my post as a question. As Alan suggested, I would like to know why em dash ligatures with surrounding spaces are not rendered as em dashes in the PDF output. It seems like a bug to me.
– Andy N
3 hours ago
add a 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
3 hours ago
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
});
}
});
Andy N is a new contributor. Be nice, and check out our Code of Conduct.
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
3 hours ago
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
3 hours ago
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 3 hours ago
Alan MunnAlan Munn
161k28429705
161k28429705
This fixes the problem. Though I'm still not sure why.
– Andy N
3 hours ago
add a comment |
This fixes the problem. Though I'm still not sure why.
– Andy N
3 hours ago
This fixes the problem. Though I'm still not sure why.
– Andy N
3 hours ago
This fixes the problem. Though I'm still not sure why.
– Andy N
3 hours ago
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 40 mins ago
Ulrike FischerUlrike Fischer
193k8302686
193k8302686
add a comment |
add a comment |
Andy N is a new contributor. Be nice, and check out our Code of Conduct.
Andy N is a new contributor. Be nice, and check out our Code of Conduct.
Andy N is a new contributor. Be nice, and check out our Code of Conduct.
Andy N is a new contributor. Be nice, and check out our Code of Conduct.
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
3 hours ago
@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
3 hours ago
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
3 hours ago
Apologies @Kurt, I did not phrase my post as a question. As Alan suggested, I would like to know why em dash ligatures with surrounding spaces are not rendered as em dashes in the PDF output. It seems like a bug to me.
– Andy N
3 hours ago