Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The :index: role and the glossary generate duplicate entries in the LaTeX index #8214

Closed
ddemange opened this issue Sep 16, 2020 · 2 comments · Fixed by #8767
Closed

The :index: role and the glossary generate duplicate entries in the LaTeX index #8214

ddemange opened this issue Sep 16, 2020 · 2 comments · Fixed by #8767

Comments

@ddemange
Copy link

Bug
A document contains both :

  • a glossary with an entry named "term"
  • some text, in which I index an occurrence of the word "term" through the role :index:`term`

The output PDF index contains a duplicate entry for the word "term":

  • one entry with a page number of the glossary entry
  • one entry with a page number of the occurrence in the text of the document
    Below is a snapshot :
    image

Expected behavior
The index should contain only one entry for the word "term", with 2 page numbers pointing to the occurrences of that word.
Expected output index :
image

Possible cause
Looking at the generated .idx file:

\indexentry{term@\spxentry{term}|hyperpage}{1}
\indexentry{term@\spxentry {term}|hyperindexformat{\spxpagem}}{3}

An extra whitespace between the command \spxentry and the argument {term} is generated from the glossary entry.
Removing that extra whitespace solves the problem.

Environment info

  • OS: Mac 10.13.6
  • Python version: 3.8.5
  • Sphinx version: 3.2.1
  • Sphinx extensions: none
  • Extra tools: none
@ddemange ddemange changed the title The :index: role and the glossary generate duplicate entries in the LaTeX index The :index: role and the glossary generate duplicate entries in the LaTeX index Sep 16, 2020
@ddemange
Copy link
Author

The problem would be due to the \index command doing tokenization of its argument.
See: https://tex.stackexchange.com/a/145326

The :index: role in the main body of the document is generating
\index{term@\spxentry{term}}

while the glossary entry is generating
{term\index{term@\spxentry{term}|spxpagem}\phantomsection\label{\detokenize{glossary:term-term}}}.

@jfbu
Copy link
Contributor

jfbu commented Jan 26, 2021

Thanks for reporting and analysis.

Using latex_use_xindy = True appears to solve this. There is only one term in the index. If both indexed term and glossary are on the same page, there is only one page link. Else there are two page links.

An indexed :index:`term` and :index:`another` one.

.. glossary::

   term
      will it generate a duplicate entry?


.. raw:: latex

   \clearpage

.. glossary::

   another
      will it generate a duplicate entry?

conf.py:

latex_use_xindy = True

we will have

\indexentry{term@\spxentry{term}}{1}
\indexentry{another@\spxentry{another}}{1}
\indexentry{term@\spxentry {term}|spxpagem}{1}
\indexentry{another@\spxentry {another}|spxpagem}{2}

but the extra spaces are fine with xindy.

Capture d’écran 2021-01-26 à 17 29 59

I will investigate if a not too complicated work-around is feasible for the makeindex route, else the fix will be to use xindy as above (testing report welcome).

edit: if testing with then without then with xindy, always do make clean because the left-over auxiliary files in latex build repertory break the build when toggling the config.

jfbu added a commit to jfbu/sphinx that referenced this issue Jan 26, 2021
… glossary

This makes .idx files contain \spxentry{..} with no space, whether or
not the \index latex command is encountered in main text or e.g. in a
label of a description list (like happens for terms from a glossary).

Xindy does not care about spaces, but Makeindex doesn't merge entries
whose typesetting is to be done via \spxentry{..} or \spxentry {..}.

An alternative work-around would be for Sphinx LaTeX writer to use some
wrapper, say, \sphinxindexwrap, only to fetch the argument and force TeX
tokenization and then hand over it to \index command.

But we choose to let \spxentry expand to its own name, with no trailing
space (it gets its final definition only from the python.ist file in
case of Makeindex).

In case both the :index: role and the glossary are on same page, Xindy
and Makeindex behave differently: the former gives only once the page
number, the latter issues them twice (but the indexed term only once),
and there is warning in the .ilg file. But this is unrelated and we
can't do here anything about it.
jfbu added a commit to jfbu/sphinx that referenced this issue Jan 26, 2021
… glossary

This makes .idx files contain \spxentry{..} with no space, whether or
not the \index latex command is encountered in main text or e.g. in a
label of a description list (like happens for terms from a glossary).

Xindy does not care about spaces, but Makeindex doesn't merge entries
whose typesetting is to be done via \spxentry{..} or \spxentry {..}.

An alternative work-around would be for Sphinx LaTeX writer to use some
wrapper, say, \sphinxindexwrap, only to fetch the argument and force TeX
tokenization and then hand over it to \index command.

But we choose to let \spxentry expand to its own name, with no trailing
space (it gets its final definition only from the python.ist file in
case of Makeindex).

In case both the :index: role and the glossary are on same page, Xindy
and Makeindex behave differently: the former gives only once the page
number, the latter issues them twice (but the indexed term only once),
and there is warning in the .ilg file. But this is unrelated and we
can't do here anything about it.
tk0miya added a commit that referenced this issue Jan 27, 2021
Fix #8214: duplicate entries in latex index if term also in glossary
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jul 14, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants