Glossaries links with non-latin labels in LuaLaTeX refer to wrong place












9















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?










share|improve this question

























  • 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


















9















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?










share|improve this question

























  • 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
















9












9








9








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?










share|improve this question
















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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





















  • 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












2 Answers
2






active

oldest

votes


















8














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}





share|improve this answer



















  • 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



















10














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}





share|improve this answer























    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
    });


    }
    });














    draft saved

    draft discarded


















    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









    8














    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}





    share|improve this answer



















    • 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
















    8














    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}





    share|improve this answer



















    • 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














    8












    8








    8







    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}





    share|improve this answer













    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}






    share|improve this answer












    share|improve this answer



    share|improve this answer










    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














    • 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











    10














    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}





    share|improve this answer




























      10














      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}





      share|improve this answer


























        10












        10








        10







        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}





        share|improve this answer













        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}






        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Jan 22 at 15:08









        Ulrike FischerUlrike Fischer

        192k8300682




        192k8300682






























            draft saved

            draft discarded




















































            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.




            draft saved


            draft discarded














            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





















































            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







            Popular posts from this blog

            Are they similar matrix

            Order of finite fields is $p^n$

            “minimization” problem in Euclidean space related to orthonormal basis