# Why \leaders and \mkern works strangely in different font size?

I can hardly determine a good title for this question, I'm sorry.

Minimal test code:

\documentclass{minimal}
\usepackage{lipsum}
\begin{document}
foo
{\fontsize{18}{18}\leaders\hbox{$\mkern 10000mu.\mkern 10000mu$}\hfill}
bar

\lipsum
\end{document}


If I compile this, bar and the result of \lipsum is gone. It's amazing. And,

• If I replace the arguments of \fontsize with 15 or 20, everything is correct!

• If I replace \hbox{$\mkern 10000mu.\mkern 10000mu$} to something else, e.g. delete one \mkern 10000mu, the result may be correct too.

I know that \fontsize changes the length of a mu unit. But I totally cannot understand what happens.

Here is an example of Plain TeX:

% fine
% Width of hbox less than \maxdimen

text text
\vfill\eject

% BAD: text after the leaders is gone
% Width of hbox more than \maxdimen

text text
\vfill\eject

% fine?
% Width of hbox more than \maxdimen

text text
\vfill\eject

\bye


I wonder why a box of 20000pt width makes wrong output, but a box of 24000pt width seems correct. I know it is an overflow thus it cannot be a bug of TeX, but what happens?

Background

The code comes from tocloft package. Now I believe it is a bug of tocloft. In tocloft, it defines

\providecommand{\cftdotfill}[1]{%
\leaders\hbox{$\m@th\mkern #1 mu\hbox{\cftdot}\mkern #1 mu$}\hfill}


And \cftnodots is 10000. Then this test file fails:

\documentclass{article}
\usepackage{tocloft}
\usepackage{lipsum}

\begin{document}

\contentsline{section}{TEST}{1}

\lipsum
\end{document}


I can fix the bug by redefining \cftdotfill to

\renewcommand{\cftdotfill}[1]{%


But the bug still shocked me.

-

The width of

\hbox{$\mkern10000mu.\mkern10000mu$}


is 16003.67247pt when the font used by LaTeX is at 14.4pt; when you ask for 17.28pt size, the box becomes 19204.52904pt wide, which is more than \maxdimen and so everything goes awry.

Notice that \fontsize{18}{18}\selectfont (the \selectfont is implicitly done when the formula begins) chooses, with the standard font, a font at 17.8pt.

When you ask for 15pt, the font chosen is at 14.4pt.

It's quite bizarre that with \fontsize{20}{20} the behavior is normal (the box is 23050.07462pt wide). But I think it's just a curiosity.

I'd say it's an oversight in tocloft.

If I load lmodern (that has scalable fonts), the limit between regular and awry is at 14.68181pt = 962187sp; at 14.68182pt = 962188sp the behavior is the strange one.

The behavior remains strange until the font size is 19.85608pt = 1301288sp and resumes to normal at 19.85609pt = 1301289sp.

## Workaround for tocloft

One way to avoid the problem is to redefine \cftnodots:

\renewcommand\cftnodots{100mu\gobbleeight}
\newcommand\gobbleeight[8]{}


In this way, \cftdotfill{\cftnodots} will expand to

\leaders\hbox{$\m@th\mkern \cftnodots mu\hbox{\cftdot}\mkern \cftnodots mu$}\hfill


and the first \mkern will expand the first \cftnodots, resulting in

\mkern100mu\gobbleeight mu\hbox{\cftdot}\mkern \cftnodots mu


and counting arguments we see that this eventually gives

\leaders\hbox{$\m@th\mkern100mu$}\hfill


which prints nothing (actually some boxes containing only white space, but it's better than an unpredictable behavior). The code in tocloft should be fixed.

-
Thank you. I can imagine that the width of box is wider than \maxdimen and something goes wrong. But I still cannot understand the difference between \fontsize{18}{18} and \fontsize{20}{20}. I'll try to make a plain TeX example. –  Leo Liu Dec 1 '11 at 5:40
@LeoLiu It's quite strange indeed; I'm doing experiments. –  egreg Dec 1 '11 at 7:25