3

I suppose I should preface this by mentioning that I am not looking for the solution to a problem, but rather for the reason the problem occurs in the first place. The problem has already been worked around.

Disclaimer: I hate Babel and never use it. The code below is someone else's. I just found the problem described here extremely odd and thought I'd enquire further.

Here's a stripped-down version of the code:

\documentclass[11pt]{book}

\usepackage[spanish]{babel}
\unaccentedoperators
\decimalpoint

\begin{document}

\mainmatter

\chapter{chapter title}

\begin{equation}\label{eq1}
1 \neq 0
\end{equation}

We thus have
\begin{equation}
2 \neq 1\ \Longleftrightarrow\ (\ref{eq1})\ \Longleftrightarrow\ 2 \neq 0
\end{equation}

\end{document}

If I remove the Babel line and the two lines immediately after it, everything compiles and I get the following:

enter image description here

(I know the fact that 2 is unequal to 0 does not follow from 0 being unequal to both 1 and 2; I just filled the equation environment with the first thing that came to mind.)

If I recompile, I get the following, as expected:

enter image description here

Now, if I use Babel (haven't tried languages other than Spanish), the code compiles the first time and I get something similar to the first image (with the ??), but the second time the compiler gets stuck forever:

enter image description here

Here's what the code owner and I have tried so far and the results:

  • The file at usr/local/texlive/2015/texmf-dist/tex/latex/wasysym/uwasy.fd, which appears at the end of the console before it gets stuck and seems to be a file where certain math symbols are defined, doesn't seem to be corrupted or anything.
  • Changing \ref{eq1} for anything other than a reference (such as simply 1.1) results in successful compilation. Thus, the problem occurs when LaTeX tries to reference the first equation.
  • Commenting (or removing) equation 1.1 results in successful compilation (obviously, the reference in the other equation is replaced by ??).
  • Referencing equation 1.1 outside of equation 1.2 results in successful compilation. Thus, LaTeX seems to dislike referencing an equation only from within another equation.
  • Referencing something other than an equation (e.g. a subsection) from within equation 1.2 results in successful compilation. Thus, LaTeX only seems to dislike referencing equations from within equations.
  • The label and contents of equation 1.1 have no bearing on the result.
  • We rewrote the entire document from scratch to check for problematic invisible characters, but there were none.
  • Commenting the \chapter line results in successful compilation. Thus, LaTeX only has problems with weuation referencing from within equations when said equations are within a chapter environment.
  • Playing around with various seemingly unrelated things (such as moving the preamble to a master file and using \include to include the chapter in question, putting equation 1.2 inside a list (\begin{itemize}), etc) sometimes results in the last line in the console being something other than the wasysym line. We didn't test enough to determine when it was wasysym and when it was something else.

Because the problem disappears when Babel is not called, my conclusion is that Babel (at least the Spanish one) must somehow mess with the chapter environment in such a way that equation referencing from within equations causes an endless loop or something similar (there is no error message; the compilation just gets stuck forever).

So my question is this: What exactly does (Spanish) Babel do to the chapter environment to cause this?

Thanks in advance.

  • I can confirm that removing everything from \usepackage[utf8]{inputenc} to \makeindex results in the exact same problem (except the last line in the console is now something else). I'll edit my post now. – Rain Sep 20 '16 at 20:28
  • @campa That answer doesn't help, unfortunately, because it refers to the fact that Spanish Babel changes decimal periods to commas, not to the fact that it also messes with equation referencing from within equations. Thanks, though. – Rain Sep 20 '16 at 20:33
4

Yes, this is due to \decimalpoint (or, better, it is related to how spanish-babel sets up things so that numbers in math are printed with either a comma or a period, depending on a \decimalpoint or \decimalcomma declaration).

Workaround: use (\mbox{\ref{eq1}})

Better yet, load amsmath and use \eqref:

\documentclass[11pt]{book}

\usepackage[spanish]{babel}
\usepackage{amsmath}

\unaccentedoperators
\decimalpoint

\begin{document}

\mainmatter

\chapter{chapter title}

\begin{equation}\label{eq1}
1 \neq 0
\end{equation}

We thus have
\begin{equation}
2 \neq 1\ \Longleftrightarrow\ \eqref{eq1}\ \Longleftrightarrow\ 2 \neq 0
\end{equation}

\end{document}

enter image description here

Here's a minimal example that falsifies some of your conclusions:

\documentclass{article}
\usepackage[spanish]{babel}
\usepackage{amsmath}

\decimalpoint

\renewcommand{\theequation}{1.\arabic{equation}}

\begin{document}
\begin{equation}\label{eq}\tracingmacros=1
\ref{eq}
\end{equation}
\end{document}

I use \tracingmacros in the equation so that macro expansion is traced in the log file. Here's what happens at the second compilation:

\ref ->\protect \ref  

\ref  #1->\@safe@activestrue \org@ref {#1}\@safe@activesfalse 
#1<-eq

\@safe@activestrue ->\let \if@safe@actives \iftrue 

\org@ref #1->\expandafter \@setref \csname r@#1\endcsname \@firstoftwo {#1}
#1<-eq

\@setref #1#2#3->\ifx #1\relax \protect \G@refundefinedtrue \nfss@text {\reset@
font \bfseries ??}\@latex@warning {Reference `#3' on page \thepage \space undef
ined}\else \expandafter #2#1\null \fi 
#1<-\r@eq 
#2<-\@firstoftwo 
#3<-eq

\r@eq ->{1.1}{1}

\@firstoftwo #1#2->#1
#1<-1.1
#2<-1

.->\es@use@shorthand .

\es@use@shorthand ->\if@safe@actives \bbl@afterelse \string \else \bbl@afterfi 
{\ifx \thepage \relax \bbl@afterelse \string \else \bbl@afterfi \es@use@sh \fi 
}\fi 

\bbl@afterelse #1\else #2\fi ->\fi #1
#1<-\string 
#2<-\bbl@afterfi {\ifx \thepage \relax \bbl@afterelse \string \else \bbl@afterf
i \es@use@sh \fi }

.->\es@use@shorthand .

The \ref macro sets \@safe@activestrue, and then, after some work, it produces 1.1. The number 1 is processed and not we get at ., which is math active (as ordered by spanish-babel), thus it behaves as a macro, but only in math mode. When \if@safe@active returns true, it becomes \string.. OK, \string. returns a period of category code 12, which is math active, so its definition as an active character is expanded again, which is \es@use@shorthand .: infinite loop, sorry.

Temporarily jumping off math mode, with \mbox, or using \eqref which implicitly uses a box, turns off any behavior of . as a math active character and solves the issue.

  • Thanks. This works. However, it doesn't tell me why Babel is causing the problem, which is the question I asked. As mentioned in the original post, we already worked around the problem and don't need another solution. – Rain Sep 21 '16 at 21:52
  • @Rain I added the analysis of the infinite loop – egreg Sep 21 '16 at 22:11
  • Thanks a lot! That explains everything except one little thing: If this problem is entirely Babel's fault (i.e. chapter has nothing to do with it) and your example gets stuck during the second compilation even without a chapter environment, why does my example work when I comment the \chapter line? – Rain Sep 22 '16 at 23:31
  • @Rain I didn't try without \chapter; I guess the 0 inserted as chapter number makes the difference, but I'm not sure. – egreg Sep 22 '16 at 23:40
3

Try:

\usepackage[spanish.nodecimaldot]{babel}

Or alternatively:

\usepackage[spanish,safe=none]{babel}

The problem is more on the babel side than on the spanish one. In fact, it's listed as a “known issue” in the babel docs.

  • As with egreg's solution, this works. However, it doesn't tell me why Babel is causing the problem either. We already worked around the problem and don't need another solution. Is it known why redefining the decimal separator messes with the chapter environment in such a way that equation references are affected? – Rain Sep 21 '16 at 21:53
  • Sure, but chapter is not involved in this issue at all. It's related to the internal redefinitions done by babel of macros like \ref or \cite to ensure shorthands can be used as “normal” characters inside them. Improving the code at this regard could break a lot of existing documents, and therefore a simple alternative approach was devised for babel 3.9 - just don't redefine them if you like, because after all these changes are not essential, and this what safe=none does. – Javier Bezos Sep 22 '16 at 14:08
  • Thanks. Please see my latest comment on egreg's post, though; I still don't understand how chapter can be not involved. – Rain Sep 22 '16 at 23:31
  • 1
    Without a chapter the label becomes just 1, and not 0.1, as you are assuming. So, there is no dot. – Javier Bezos Sep 23 '16 at 15:10
  • Ah. That makes perfect sense. Thank you. I can't accept two answers, so I accepted egreg's because it addresses the infinite loop, but thanks a lot for explaining chapter's indirect involvement in the issue. :) – Rain Sep 24 '16 at 13:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.