Glossaries links with non-latin labels in LuaLaTeX refer to wrong place
I want to make a glossary with glossaries-extra
package and use Cyrillic characters as entries labels. Everything works fine with XeLaTeX
. Clickable links refer to exact glossary entry. But in LuaLaTeX
links doesn't work properly. They refer to wrong place.
Entries with Latin link works fine in every case.
MWE:
documentclass{article}
usepackage{polyglossia}
setmainfont{Liberation Serif}
usepackage{hyperref}
usepackage[nonumberlist]{glossaries-extra}
newglossaryentry{язык}{ name={язык},
sort=lowercase{язык},
description={Система общения людей.}}
newglossaryentry{компьютер}{ name={компьютер},
sort=lowercase{компьютер},
description={Вычислительная машина.}}
makeglossaries[main]
begin{document}
section*{Словарь}
printglossary[style=list,title={}]
forallglossaries{thistype}{section{Glossary `thistype'}
forglsentries[thistype]{thislabel}{gls{thislabel}. }}
end{document}
Is there a way to get right links in pdf with LuaLaTeX?
hyperref luatex pdf glossaries glossaries-extra
add a comment |
I want to make a glossary with glossaries-extra
package and use Cyrillic characters as entries labels. Everything works fine with XeLaTeX
. Clickable links refer to exact glossary entry. But in LuaLaTeX
links doesn't work properly. They refer to wrong place.
Entries with Latin link works fine in every case.
MWE:
documentclass{article}
usepackage{polyglossia}
setmainfont{Liberation Serif}
usepackage{hyperref}
usepackage[nonumberlist]{glossaries-extra}
newglossaryentry{язык}{ name={язык},
sort=lowercase{язык},
description={Система общения людей.}}
newglossaryentry{компьютер}{ name={компьютер},
sort=lowercase{компьютер},
description={Вычислительная машина.}}
makeglossaries[main]
begin{document}
section*{Словарь}
printglossary[style=list,title={}]
forallglossaries{thistype}{section{Glossary `thistype'}
forglsentries[thistype]{thislabel}{gls{thislabel}. }}
end{document}
Is there a way to get right links in pdf with LuaLaTeX?
hyperref luatex pdf glossaries glossaries-extra
Interestingly it works for me if I use ASCII-only labels, i.e.newglossaryentry{jazik}{...}
&newglossaryentry{komputer}{...}
– moewe
Jan 22 at 13:53
@moewe Yes, with ASCII-only labels it works for me too. But I need Cyrillic labels
– Shalom Alecheim
Jan 22 at 14:03
Ah bummer, since the labels are only used as internal identifiers and never exposed in the document, I thought you could be OK with using ASCII-only labels. That said, since LuaLaTeX is supposed to be a Unicode engine I would expect things to work with Cyrillic as well.
– moewe
Jan 22 at 14:06
add a comment |
I want to make a glossary with glossaries-extra
package and use Cyrillic characters as entries labels. Everything works fine with XeLaTeX
. Clickable links refer to exact glossary entry. But in LuaLaTeX
links doesn't work properly. They refer to wrong place.
Entries with Latin link works fine in every case.
MWE:
documentclass{article}
usepackage{polyglossia}
setmainfont{Liberation Serif}
usepackage{hyperref}
usepackage[nonumberlist]{glossaries-extra}
newglossaryentry{язык}{ name={язык},
sort=lowercase{язык},
description={Система общения людей.}}
newglossaryentry{компьютер}{ name={компьютер},
sort=lowercase{компьютер},
description={Вычислительная машина.}}
makeglossaries[main]
begin{document}
section*{Словарь}
printglossary[style=list,title={}]
forallglossaries{thistype}{section{Glossary `thistype'}
forglsentries[thistype]{thislabel}{gls{thislabel}. }}
end{document}
Is there a way to get right links in pdf with LuaLaTeX?
hyperref luatex pdf glossaries glossaries-extra
I want to make a glossary with glossaries-extra
package and use Cyrillic characters as entries labels. Everything works fine with XeLaTeX
. Clickable links refer to exact glossary entry. But in LuaLaTeX
links doesn't work properly. They refer to wrong place.
Entries with Latin link works fine in every case.
MWE:
documentclass{article}
usepackage{polyglossia}
setmainfont{Liberation Serif}
usepackage{hyperref}
usepackage[nonumberlist]{glossaries-extra}
newglossaryentry{язык}{ name={язык},
sort=lowercase{язык},
description={Система общения людей.}}
newglossaryentry{компьютер}{ name={компьютер},
sort=lowercase{компьютер},
description={Вычислительная машина.}}
makeglossaries[main]
begin{document}
section*{Словарь}
printglossary[style=list,title={}]
forallglossaries{thistype}{section{Glossary `thistype'}
forglsentries[thistype]{thislabel}{gls{thislabel}. }}
end{document}
Is there a way to get right links in pdf with LuaLaTeX?
hyperref luatex pdf glossaries glossaries-extra
hyperref luatex pdf glossaries glossaries-extra
edited Jan 22 at 15:55
Shalom Alecheim
asked Jan 22 at 13:50
Shalom AlecheimShalom Alecheim
1146
1146
Interestingly it works for me if I use ASCII-only labels, i.e.newglossaryentry{jazik}{...}
&newglossaryentry{komputer}{...}
– moewe
Jan 22 at 13:53
@moewe Yes, with ASCII-only labels it works for me too. But I need Cyrillic labels
– Shalom Alecheim
Jan 22 at 14:03
Ah bummer, since the labels are only used as internal identifiers and never exposed in the document, I thought you could be OK with using ASCII-only labels. That said, since LuaLaTeX is supposed to be a Unicode engine I would expect things to work with Cyrillic as well.
– moewe
Jan 22 at 14:06
add a comment |
Interestingly it works for me if I use ASCII-only labels, i.e.newglossaryentry{jazik}{...}
&newglossaryentry{komputer}{...}
– moewe
Jan 22 at 13:53
@moewe Yes, with ASCII-only labels it works for me too. But I need Cyrillic labels
– Shalom Alecheim
Jan 22 at 14:03
Ah bummer, since the labels are only used as internal identifiers and never exposed in the document, I thought you could be OK with using ASCII-only labels. That said, since LuaLaTeX is supposed to be a Unicode engine I would expect things to work with Cyrillic as well.
– moewe
Jan 22 at 14:06
Interestingly it works for me if I use ASCII-only labels, i.e.
newglossaryentry{jazik}{...}
& newglossaryentry{komputer}{...}
– moewe
Jan 22 at 13:53
Interestingly it works for me if I use ASCII-only labels, i.e.
newglossaryentry{jazik}{...}
& newglossaryentry{komputer}{...}
– moewe
Jan 22 at 13:53
@moewe Yes, with ASCII-only labels it works for me too. But I need Cyrillic labels
– Shalom Alecheim
Jan 22 at 14:03
@moewe Yes, with ASCII-only labels it works for me too. But I need Cyrillic labels
– Shalom Alecheim
Jan 22 at 14:03
Ah bummer, since the labels are only used as internal identifiers and never exposed in the document, I thought you could be OK with using ASCII-only labels. That said, since LuaLaTeX is supposed to be a Unicode engine I would expect things to work with Cyrillic as well.
– moewe
Jan 22 at 14:06
Ah bummer, since the labels are only used as internal identifiers and never exposed in the document, I thought you could be OK with using ASCII-only labels. That said, since LuaLaTeX is supposed to be a Unicode engine I would expect things to work with Cyrillic as well.
– moewe
Jan 22 at 14:06
add a comment |
2 Answers
2
active
oldest
votes
As Ulrike Fischer described the problem is that non-ASCII characters are dropped by pdf@escapestring
. To avoid this, you can change pdf@escapestring
to encode Unicode characters in UTF-8:
documentclass{article}
usepackage{polyglossia}
setmainfont{Liberation Serif}
usepackage{hyperref}
usepackage[nonumberlist]{glossaries-extra}
newglossaryentry{язык}{ name={язык},
sort=lowercase{язык},
description={Система общения людей.}}
newglossaryentry{компьютер}{ name={компьютер},
sort=lowercase{компьютер},
description={Вычислительная машина.}}
makeglossaries[main]
makeatletter
longdefpdf@escapestring#1{%
directlua0{%
oberdiek.pdftexcmds.escapestring("luaescapestring{#1}")% Almost like the original one, just omit "byte" to keep all characters.
}%
}
makeatother
begin{document}
section*{Словарь}
printglossary[style=list,title={}]
forallglossaries{thistype}{section{Glossary `thistype'}
forglsentries[thistype]{thislabel}{gls{thislabel}. }}
end{document}
1
I will have to check if this always gives a valid pdf string. But if yes, this should probably be implemented.
– Ulrike Fischer
Jan 22 at 17:15
@UlrikeFischer I am quite sure that it always gives a valid PDF string. (It corresponds to a valid PDFDocEncoding string, at least if U+7F=Delete is not used, because 0x7f is undefined for PDFDocEncoding) But it does not generate a valid encoding of the passed string, because PDF only accepts PDFDocEncodung and UTF-16, not UTF-8.
– Marcel Krüger
Jan 22 at 18:02
add a comment |
Not a solution but an explanation. The problem is hyperref. hyperref uses with lualatex pdf@escapestring
to convert the name to something that can be safely used as a destination in the pdf. But the current implementation of pdf@escapestring
handles only ascii, everything else is simply dropped. And this means that glossaries creates for the two entries the same destination glo:
On the terminal you can see the warning
warning (pdf backend): ignoring duplicate destination with the name 'glo:'
when trying this document:
documentclass{article}
usepackage{hyperref}
begin{document}
makeatletter
pdf@escapestring {glo:компьютер}
pdf@escapestring {glo:язык}
hypertarget{glo:компьютер}{blub}
hypertarget{glo:язык}{bla}
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%2f471279%2fglossaries-links-with-non-latin-labels-in-lualatex-refer-to-wrong-place%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
As Ulrike Fischer described the problem is that non-ASCII characters are dropped by pdf@escapestring
. To avoid this, you can change pdf@escapestring
to encode Unicode characters in UTF-8:
documentclass{article}
usepackage{polyglossia}
setmainfont{Liberation Serif}
usepackage{hyperref}
usepackage[nonumberlist]{glossaries-extra}
newglossaryentry{язык}{ name={язык},
sort=lowercase{язык},
description={Система общения людей.}}
newglossaryentry{компьютер}{ name={компьютер},
sort=lowercase{компьютер},
description={Вычислительная машина.}}
makeglossaries[main]
makeatletter
longdefpdf@escapestring#1{%
directlua0{%
oberdiek.pdftexcmds.escapestring("luaescapestring{#1}")% Almost like the original one, just omit "byte" to keep all characters.
}%
}
makeatother
begin{document}
section*{Словарь}
printglossary[style=list,title={}]
forallglossaries{thistype}{section{Glossary `thistype'}
forglsentries[thistype]{thislabel}{gls{thislabel}. }}
end{document}
1
I will have to check if this always gives a valid pdf string. But if yes, this should probably be implemented.
– Ulrike Fischer
Jan 22 at 17:15
@UlrikeFischer I am quite sure that it always gives a valid PDF string. (It corresponds to a valid PDFDocEncoding string, at least if U+7F=Delete is not used, because 0x7f is undefined for PDFDocEncoding) But it does not generate a valid encoding of the passed string, because PDF only accepts PDFDocEncodung and UTF-16, not UTF-8.
– Marcel Krüger
Jan 22 at 18:02
add a comment |
As Ulrike Fischer described the problem is that non-ASCII characters are dropped by pdf@escapestring
. To avoid this, you can change pdf@escapestring
to encode Unicode characters in UTF-8:
documentclass{article}
usepackage{polyglossia}
setmainfont{Liberation Serif}
usepackage{hyperref}
usepackage[nonumberlist]{glossaries-extra}
newglossaryentry{язык}{ name={язык},
sort=lowercase{язык},
description={Система общения людей.}}
newglossaryentry{компьютер}{ name={компьютер},
sort=lowercase{компьютер},
description={Вычислительная машина.}}
makeglossaries[main]
makeatletter
longdefpdf@escapestring#1{%
directlua0{%
oberdiek.pdftexcmds.escapestring("luaescapestring{#1}")% Almost like the original one, just omit "byte" to keep all characters.
}%
}
makeatother
begin{document}
section*{Словарь}
printglossary[style=list,title={}]
forallglossaries{thistype}{section{Glossary `thistype'}
forglsentries[thistype]{thislabel}{gls{thislabel}. }}
end{document}
1
I will have to check if this always gives a valid pdf string. But if yes, this should probably be implemented.
– Ulrike Fischer
Jan 22 at 17:15
@UlrikeFischer I am quite sure that it always gives a valid PDF string. (It corresponds to a valid PDFDocEncoding string, at least if U+7F=Delete is not used, because 0x7f is undefined for PDFDocEncoding) But it does not generate a valid encoding of the passed string, because PDF only accepts PDFDocEncodung and UTF-16, not UTF-8.
– Marcel Krüger
Jan 22 at 18:02
add a comment |
As Ulrike Fischer described the problem is that non-ASCII characters are dropped by pdf@escapestring
. To avoid this, you can change pdf@escapestring
to encode Unicode characters in UTF-8:
documentclass{article}
usepackage{polyglossia}
setmainfont{Liberation Serif}
usepackage{hyperref}
usepackage[nonumberlist]{glossaries-extra}
newglossaryentry{язык}{ name={язык},
sort=lowercase{язык},
description={Система общения людей.}}
newglossaryentry{компьютер}{ name={компьютер},
sort=lowercase{компьютер},
description={Вычислительная машина.}}
makeglossaries[main]
makeatletter
longdefpdf@escapestring#1{%
directlua0{%
oberdiek.pdftexcmds.escapestring("luaescapestring{#1}")% Almost like the original one, just omit "byte" to keep all characters.
}%
}
makeatother
begin{document}
section*{Словарь}
printglossary[style=list,title={}]
forallglossaries{thistype}{section{Glossary `thistype'}
forglsentries[thistype]{thislabel}{gls{thislabel}. }}
end{document}
As Ulrike Fischer described the problem is that non-ASCII characters are dropped by pdf@escapestring
. To avoid this, you can change pdf@escapestring
to encode Unicode characters in UTF-8:
documentclass{article}
usepackage{polyglossia}
setmainfont{Liberation Serif}
usepackage{hyperref}
usepackage[nonumberlist]{glossaries-extra}
newglossaryentry{язык}{ name={язык},
sort=lowercase{язык},
description={Система общения людей.}}
newglossaryentry{компьютер}{ name={компьютер},
sort=lowercase{компьютер},
description={Вычислительная машина.}}
makeglossaries[main]
makeatletter
longdefpdf@escapestring#1{%
directlua0{%
oberdiek.pdftexcmds.escapestring("luaescapestring{#1}")% Almost like the original one, just omit "byte" to keep all characters.
}%
}
makeatother
begin{document}
section*{Словарь}
printglossary[style=list,title={}]
forallglossaries{thistype}{section{Glossary `thistype'}
forglsentries[thistype]{thislabel}{gls{thislabel}. }}
end{document}
answered Jan 22 at 16:21
Marcel KrügerMarcel Krüger
11.8k11535
11.8k11535
1
I will have to check if this always gives a valid pdf string. But if yes, this should probably be implemented.
– Ulrike Fischer
Jan 22 at 17:15
@UlrikeFischer I am quite sure that it always gives a valid PDF string. (It corresponds to a valid PDFDocEncoding string, at least if U+7F=Delete is not used, because 0x7f is undefined for PDFDocEncoding) But it does not generate a valid encoding of the passed string, because PDF only accepts PDFDocEncodung and UTF-16, not UTF-8.
– Marcel Krüger
Jan 22 at 18:02
add a comment |
1
I will have to check if this always gives a valid pdf string. But if yes, this should probably be implemented.
– Ulrike Fischer
Jan 22 at 17:15
@UlrikeFischer I am quite sure that it always gives a valid PDF string. (It corresponds to a valid PDFDocEncoding string, at least if U+7F=Delete is not used, because 0x7f is undefined for PDFDocEncoding) But it does not generate a valid encoding of the passed string, because PDF only accepts PDFDocEncodung and UTF-16, not UTF-8.
– Marcel Krüger
Jan 22 at 18:02
1
1
I will have to check if this always gives a valid pdf string. But if yes, this should probably be implemented.
– Ulrike Fischer
Jan 22 at 17:15
I will have to check if this always gives a valid pdf string. But if yes, this should probably be implemented.
– Ulrike Fischer
Jan 22 at 17:15
@UlrikeFischer I am quite sure that it always gives a valid PDF string. (It corresponds to a valid PDFDocEncoding string, at least if U+7F=Delete is not used, because 0x7f is undefined for PDFDocEncoding) But it does not generate a valid encoding of the passed string, because PDF only accepts PDFDocEncodung and UTF-16, not UTF-8.
– Marcel Krüger
Jan 22 at 18:02
@UlrikeFischer I am quite sure that it always gives a valid PDF string. (It corresponds to a valid PDFDocEncoding string, at least if U+7F=Delete is not used, because 0x7f is undefined for PDFDocEncoding) But it does not generate a valid encoding of the passed string, because PDF only accepts PDFDocEncodung and UTF-16, not UTF-8.
– Marcel Krüger
Jan 22 at 18:02
add a comment |
Not a solution but an explanation. The problem is hyperref. hyperref uses with lualatex pdf@escapestring
to convert the name to something that can be safely used as a destination in the pdf. But the current implementation of pdf@escapestring
handles only ascii, everything else is simply dropped. And this means that glossaries creates for the two entries the same destination glo:
On the terminal you can see the warning
warning (pdf backend): ignoring duplicate destination with the name 'glo:'
when trying this document:
documentclass{article}
usepackage{hyperref}
begin{document}
makeatletter
pdf@escapestring {glo:компьютер}
pdf@escapestring {glo:язык}
hypertarget{glo:компьютер}{blub}
hypertarget{glo:язык}{bla}
end{document}
add a comment |
Not a solution but an explanation. The problem is hyperref. hyperref uses with lualatex pdf@escapestring
to convert the name to something that can be safely used as a destination in the pdf. But the current implementation of pdf@escapestring
handles only ascii, everything else is simply dropped. And this means that glossaries creates for the two entries the same destination glo:
On the terminal you can see the warning
warning (pdf backend): ignoring duplicate destination with the name 'glo:'
when trying this document:
documentclass{article}
usepackage{hyperref}
begin{document}
makeatletter
pdf@escapestring {glo:компьютер}
pdf@escapestring {glo:язык}
hypertarget{glo:компьютер}{blub}
hypertarget{glo:язык}{bla}
end{document}
add a comment |
Not a solution but an explanation. The problem is hyperref. hyperref uses with lualatex pdf@escapestring
to convert the name to something that can be safely used as a destination in the pdf. But the current implementation of pdf@escapestring
handles only ascii, everything else is simply dropped. And this means that glossaries creates for the two entries the same destination glo:
On the terminal you can see the warning
warning (pdf backend): ignoring duplicate destination with the name 'glo:'
when trying this document:
documentclass{article}
usepackage{hyperref}
begin{document}
makeatletter
pdf@escapestring {glo:компьютер}
pdf@escapestring {glo:язык}
hypertarget{glo:компьютер}{blub}
hypertarget{glo:язык}{bla}
end{document}
Not a solution but an explanation. The problem is hyperref. hyperref uses with lualatex pdf@escapestring
to convert the name to something that can be safely used as a destination in the pdf. But the current implementation of pdf@escapestring
handles only ascii, everything else is simply dropped. And this means that glossaries creates for the two entries the same destination glo:
On the terminal you can see the warning
warning (pdf backend): ignoring duplicate destination with the name 'glo:'
when trying this document:
documentclass{article}
usepackage{hyperref}
begin{document}
makeatletter
pdf@escapestring {glo:компьютер}
pdf@escapestring {glo:язык}
hypertarget{glo:компьютер}{blub}
hypertarget{glo:язык}{bla}
end{document}
answered Jan 22 at 15:08
Ulrike FischerUlrike Fischer
192k8300682
192k8300682
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%2f471279%2fglossaries-links-with-non-latin-labels-in-lualatex-refer-to-wrong-place%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
Interestingly it works for me if I use ASCII-only labels, i.e.
newglossaryentry{jazik}{...}
&newglossaryentry{komputer}{...}
– moewe
Jan 22 at 13:53
@moewe Yes, with ASCII-only labels it works for me too. But I need Cyrillic labels
– Shalom Alecheim
Jan 22 at 14:03
Ah bummer, since the labels are only used as internal identifiers and never exposed in the document, I thought you could be OK with using ASCII-only labels. That said, since LuaLaTeX is supposed to be a Unicode engine I would expect things to work with Cyrillic as well.
– moewe
Jan 22 at 14:06