# elsarticle frontmatter: Overfull \hbox has occurred while \output is active

Minimal working example

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

\begin{document}
\begin{frontmatter}

\end{frontmatter}
\end{document}


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)

• 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 – Phelype Oleinik Oct 30 '19 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 – JoKalliauer Oct 31 '19 at 11:21
• 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. – Phelype Oleinik Oct 31 '19 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 – JoKalliauer Nov 1 '19 at 16:51
• 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... – Phelype Oleinik Nov 1 '19 at 17:24

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{%
\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:

1. Copy the definition above to your document and add a % right after the }:

         \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 :-)

• The third option seems good, because it does not need to copy the entire definition. But how does it work? Mainly, why \romannumeral? – LaTeXer Nov 6 '19 at 16:59
• @LaTeXer I added an explanation about the \romannumeral trickery and a fourth option. – Phelype Oleinik Nov 6 '19 at 20:30