It sounds like xindy is unable to determine how to sort one or more of your entries, but without a minimal example it's hard to tell exactly. The default is for xindy to sort on the entry name
unless you have specified a sort
value. However, xindy ignores (La)TeX commands so if the sort key only contains commands, xindy is left with a blank sort key and issues a warning. Earlier versions of xindy gave a somewhat cryptic error:
ERROR: CHAR: index 0 should be less than the length of the string
Newer versions give a slightly more understandable warning:
WARNING: Would replace complete index key by empty string, ignoring
Since the first warning isn't very easy to understand, makeglossaries
searches for instances of it and if found gives the warning:
Possible cause of problem: Sort key required for entries only containing command names
Here's a minimal example illustrating the problem:
\documentclass{article}
\usepackage[xindy]{glossaries}
\makeglossaries
\newglossaryentry{P}{name={\P},description={Paragraph symbol}}
\newglossaryentry{S}{name={\S},description={Section symbol}}
\begin{document}
Reference the terms: \gls{S} \gls{P}.
\printglossaries
\end{document}
In this case the first term has the sort key \P
and the second term has the sort key \S
. In both cases, once xindy has stripped out the commands, it's left with an empty sort string and doesn't know how to compare the entries. Should \P
come before or after \S
? The solution is to provide a sort key for these entries:
\documentclass{article}
\usepackage[xindy]{glossaries}
\makeglossaries
\newglossaryentry{P}{name={\P},sort={P},description={Paragraph symbol}}
\newglossaryentry{S}{name={\S},sort={S},description={Section symbol}}
\begin{document}
Reference the terms: \gls{S} \gls{P}.
\printglossaries
\end{document}
If all your terms are like this (for example they are all symbols) then it may not make any sense trying to sort them alphabetically. In which case it might be better to sort them by definition (package option sort=def
, as you mentioned in your comment) or by use in the document. In either of these cases, glossaries
manufactures a numerical sort key for each term, so the issue no longer arises.
Edit: There's a GUI diagnostic tool for the glossaries
package called makeglossariesgui
which can provide further details by analysing the .aux
, .log
and associated glossary files. The example below has three problematic entries and a working one for comparison:
\documentclass{article}
\usepackage[utf8]{inputenc}
\usepackage[xindy]{glossaries}
\makeglossaries
\newglossaryentry{sample}{name={sample},
description={an example}}
\newglossaryentry{S}{name={\S},
description={section symbol}}
\newglossaryentry{alpha}{name={\ensuremath{\alpha}},
description={alpha}}
\newglossaryentry{beta}{name={$\beta$},text={\beta},
description={beta}}
\begin{document}
Test: \gls{sample}, \gls{S}, $\gls{alpha}$, $\gls{beta}$.
\printglossaries
\end{document}
A LaTeX run is first required to generate the .aux
file (although this is usually already present if you're trying to work out why xindy
has failed). The .aux
file can then be opened in makeglossariesgui
using the File > Open menu item.
For the above MWE, an error dialog is displayed to show that xindy
failed:
Once that dialog box is dismissed, the "Diagnostics" tab lists each problem:
The text displayed is:
Xindy won't accept the sort value \S
(for entry S
) as it's treated as
an empty string. This is because xindy ignores (La)TeX commands within
the sort field, and once these commands have been stripped the sort
field becomes empty. You will need to explicitly set the sort field
using the sort
key in the entry definition.
Xindy won't accept the sort value \ensuremath {\alpha }
(for entry alpha
) as it's treated as
an empty string. This is because xindy ignores (La)TeX commands within
the sort field, and once these commands have been stripped the sort
field becomes empty. You will need to explicitly set the sort field
using the sort
key in the entry definition.
Xindy won't accept the sort value $\beta $
(for entry beta
) as it's treated as an empty
string. This is because xindy ignores (La)TeX commands within the sort
field, and once these commands have been stripped the sort field
becomes empty. You will need to explicitly set the sort field using
the sort
key in the entry definition.
Xindy reported the following:
WARNING: Would replace complete index key by empty string, ignoring
#<ordrule-regexp: '\\[a-zA-Z@]+ *' => '' :again NIL :only-at-start NIL
ERROR: CHAR: index 0 should be less than the length of the string
So this explicitly identifies each problematic entry by its label (which neither xindy
nor makeglossaries
do).
The "General Information" tab contains a "Details" link, which when clicked on opens a window with a summary of all the entries. The second column shows the sort key, which is displayed in red if there's a problem with it.
Once the problems have been fixed, you can switch back to using makeglossaries
or explicitly xindy
.
Incidentally, the glossaries-extra
package, provides the command \glsxtrnewsymbol
when the symbols
package option is used. This internally uses \newglossaryentry
but sets the sort
value to the label rather than the name
field. For example:
\glsxtrnewsymbol[text={\beta},description={beta example}]{beta}{$\beta$}
This is equivalent to
\newglossaryentry{beta}{name={$\beta$},text={\beta},
sort={beta},
type=symbols,
category=symbol,
description={beta example}}
Best Answer
You must set document language to german to let
glossaries
know how it should sort entries. Due toxindy
bug, you also have to set encoding manually:Important lines are
\usepackage[german]{babel}
and\GlsSetXdyCodePage{duden-utf8}
. Note that you missed comma inAgypten
glossary entry.Edit: if
makeglossaries
still don't work, try this: