10

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
a\leaders\hbox{\kern8000pt.\kern8000pt}\hfill b

text text
\vfill\eject

% BAD: text after the leaders is gone
% Width of hbox more than \maxdimen
a\leaders\hbox{\kern10000pt.\kern10000pt}\hfill b

text text
\vfill\eject

% fine?
% Width of hbox more than \maxdimen
a\leaders\hbox{\kern12000pt.\kern12000pt}\hfill b

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}
\renewcommand{\cftsecleader}{\fontsize{16}{19}\cftdotfill{\cftnodots}}
\usepackage{lipsum}

\begin{document}

\contentsline{section}{TEST}{1}

\lipsum
\end{document}

I can fix the bug by redefining \cftdotfill to

\renewcommand{\cftdotfill}[1]{%
  \leaders\hbox to #1\p@{\hss\cftdot\hss}\hfill}

But the bug still shocked me.

1 Answer 1

10

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.

2
  • 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, 2011 at 5:40
  • @LeoLiu It's quite strange indeed; I'm doing experiments.
    – egreg
    Dec 1, 2011 at 7:25

You must log in to answer this question.

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