6

Minimal working example

% !TeX TS-program = pdflatex
% !TeX encoding = UTF-8
\documentclass{elsarticle}

\begin{document}
\begin{frontmatter}

\end{frontmatter}
\end{document}

leads to

Overfull \hbox (2.22221pt too wide) has occurred while \output is active []

The same warning occurs if I use the original template from:

I'm using

This is pdfTeX, Version 3.14159265-2.6-1.40.20 (MiKTeX 2.9.7200 64-bit)

and my packages are all up to date (as of 30.Oct.2019) and I have the newest version of elsarticle: https://ctan.org/pkg/elsarticle (06.April.2019)

7
  • 1
    Try updating the elsarticle package in the MiKTeX package manager. In the current version this has been fixed. It was a case of a missing %. There's this comment in the code now: }% <--- I added this on May 19th, 2019 Commented Oct 30, 2019 at 12:20
  • @PhelypeOleinik Thanks for your answer, but MikTeX tells me "There are currently no updates available. Try again tomorrow." I checked the elsartilce package on my computer which was installed on the 04.06.19(June) with the version of 06.04.19(April), which is the current package at ctan.org/pkg/elsarticle Commented Oct 31, 2019 at 11:21
  • 2
    Odd. This version has been around for a while now, so it should be available. Perhaps try a different mirror. And don't trust the dates. My TeXLive 2019 version of elsarticle is dated 2019/02/25, the documentation is dated 2019/04/06, and it has the comment-from-the-future from 2019/05/19 :-) Search for your version and look for the line that says Preprint submitted to \ifx\@journal\@empty. Some 6 lines below this one there should be a single } in a line of its own. Edit the file and make sure it reads }% instead. Commented Oct 31, 2019 at 11:37
  • Thanks that solved the problem. :-D Ps the file was located at C:\Program Files\MiKTeX 2.9\tex\latex\elsarticle\elsarticle.cls Commented Nov 1, 2019 at 16:51
  • 1
    Great! Warnings are annoying. Although this specific one wouldn't do any visible harm. However it is strange that you don't have the elsarticle update available... Commented Nov 1, 2019 at 17:24

1 Answer 1

8

This is a bug in elsarticle introduced some time in 2018 (in TeXLive 2017 it's fine), caused by the usual missing % at the end of the line. The guilty definition is:

\def\ps@pprintTitle{%
     \let\@oddhead\@empty
     \let\@evenhead\@empty
     \def\@oddfoot
       {\hbox to \textwidth%
        {\ifnopreprintline\relax\else
        \@myfooterfont%
         \ifx\@elsarticlemyfooteralign\@elsarticlemyfooteraligncenter%
           \hfil\@elsarticlemyfooter\hfil%
         \else%
         \ifx\@elsarticlemyfooteralign\@elsarticlemyfooteralignleft%
           \@elsarticlemyfooter\hfill{}%
         \else%
         \ifx\@elsarticlemyfooteralign\@elsarticlemyfooteralignright%
           {}\hfill\@elsarticlemyfooter%
         \else%
               Preprint submitted to \ifx\@journal\@empty%
                 Elsevier%
            \else\@journal\fi\hfill\@date\fi%
         \fi%
         \fi%
         \fi%
         }                     % <------------
       }%
     \let\@evenfoot\@oddfoot}

where the line marked with % <-- should contain a % right after the }. (Funnily enough, most of the end of line % in this definition are useless :-)

Here are four options to fix this (all except 2 should go after elsarticle is loaded, or they will have no effect):

  1. Copy the definition above to your document and add a % right after the } (and make sure to add \makeatletter and \makeatother around the definition):

             \fi%
             \fi%
             }% <--- Here
           }%
         \let\@evenfoot\@oddfoot}
    
  2. Make a local copy of elsarticle.cls and do the same.

  3. Patching with \patchcmd is tricky1 because the extra space is between two }. But it's possible with some brace hacking and \romannumeral. Adding this to your preamble should also fix the problem:

    \usepackage{etoolbox}
    \makeatletter
    \patchcmd\ps@pprintTitle
      {\fi\fi\fi\fi}
      {\fi\fi\fi\fi
       \afterassignment\fix@elsarticle\let\@tempa}
      {}{\FailedToPatch}
    \def\fix@elsarticle{\iffalse{\fi}\romannumeral-`0}
    \makeatother
    
  4. LaTeX3's regex engine doesn't abide by the same rules as \patchcmd, so you can directly replace } } by }}:

    \usepackage{regexpatch}
    \makeatletter
    \regexpatchcmd\ps@pprintTitle
      {\cE\}\ \cE\}}{\cE\}\cE\}}
      {}{\FailedToPatch}
    \makeatother
    

1 Patching that bug with etoolbox is tricky because the patch would need to replace the sequence } } by }}. The issue with this is that you can't have unbalanced braces in the argument of \patchcmd (of any macro, in fact). Actually, the braces are not really necessary, but we need some way to distinguish the space we actually want to remove from, say, the one between Preprint and submitted.

The end of the definition of \ps@pprintTitle reads:

%            V space we want to remove
\fi\fi\fi\fi} }\let\@evenfoot\@oddfoot

The patch I proposed above hooks at the four consecutive \fi in the macro and appends \afterassignment\fix@elsarticle\let\@tempa to them:

%                              space we want to remove V
\fi\fi\fi\fi\afterassignment\fix@elsarticle\let\@tempa} }

When the code execution arrives there, the four \fi do their thing as usual and disappear. \afterassignment stores the token \fix@elsarticle in a temporary memory which will be retrieved after the next assignment. The very next thing is \let\@tempa}. This instruction stores the token } in \@tempa (the same as \egroup) and as a consequence, removes it from the token stream. However now (keep this in mind) we have unbalanced TeX's brace count by removing a }.

But notice that what just happened (\let) was an assignment. TeX now triggers the \afterassignment token \fix@elsarticle, which then expands to its definition. So far, the input stream looks like this:

%                            V space we want to remove
\iffalse{\fi}\romannumeral-`0 }

Now the \iffalse expands consuming the {. This brace removal balances out the other brace we removed before, and the very next token is a }, which acts as that same brace we removed. Now all that's left is \romannumeral-`0 }. \romannumeral starts by reading in -`0, which is some negative value. Then, as other TeX primitives which scan a number, it consumes an optional space after the number, which finally removes the pesky space. However, since the read integer is negative, the expansion of \romannumeral is empty and the rest of the code runs fine. What a ride :-)

6
  • The third option seems good, because it does not need to copy the entire definition. But how does it work? Mainly, why \romannumeral?
    – LaTeXer
    Commented Nov 6, 2019 at 16:59
  • @LaTeXer I added an explanation about the \romannumeral trickery and a fourth option. Commented Nov 6, 2019 at 20:30
  • Not sure if this is because Overleaf seems to have recently updated its error log functionality, but I'm finding that (1) doesn't work, while (3) and (4) make the error go away, although Overleaf still says "Your code has errors that need to be fixed before the auto-compile can run" (even though no errors appear under this message).
    – WillG
    Commented Jul 20, 2021 at 17:51
  • @WillG Hm... I just tried the four solutions here with the example in the question and they work (note that (1) needs \makeatletter and \makeatother to work; I'll add that to the answer). Can you show an example code that doesn't work? Also, which version of TeX Live are you using on Overleaf? (you can find that under the Menu tab) Commented Jul 20, 2021 at 18:11
  • Actually, (4) seems to be fully working for me now, for some reason. Not sure if refreshing the page could have made a difference? Was using pdfLaTeX compiler for TeX live version 2020, but probably no longer relevant since it's working now :)
    – WillG
    Commented Jul 20, 2021 at 18:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .