TeX - LaTeX Stack Exchange is a question and answer site for users of TeX, LaTeX, ConTeXt, and related typesetting systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I was writing a specification document needing numbered paragraphs. I implemented it like this:


        \marginpar{\hfill\ttfamily\bfseries\arabic{paragraph} \textsection}%




This however gives odd page breaks. Specifically, the page breaks several paragraphs before the end of the page.

I determined that this was caused by the use of \marginpar{...} and replaced it with


which solves the problem.

I would however like to know what really happened here. Why does \marginpar affect the page breaking?

Here's a MWE:










\CountedSection{Lipsum 1}
Lorem ipsum dolor sit amet, consectetur adipiscing elit.

Praesent mollis ornare ullamcorper.

Nunc fringilla luctus justo auctor consequat.

Sed fringilla metus facilisis diam ultrices eleifend.

Sed eget leo nec neque lobortis hendrerit.

In fringilla dui vitae lectus vehicula a vehicula dui bibendum.

Nunc condimentum, nunc nec feugiat ornare, augue dolor lobortis arcu, id posuere neque orci at enim.

Sed vehicula, nibh a tristique imperdiet, ante erat vulputate nulla, in accumsan odio felis at odio.

Fusce orci lorem, sollicitudin sed imperdiet vitae, fermentum ut urna.

Etiam nec iaculis diam. Duis ante elit, imperdiet id ornare sit amet, porta porttitor nunc.

Nullam magna sem, imperdiet eget fermentum et, accumsan ut enim.

\CountedSection{Lipsum 2}
Vivamus consequat volutpat quam, eu sollicitudin ligula varius vitae.

Maecenas tortor mi, molestie at faucibus vitae, dapibus eget nibh. In hac habitasse platea dictumst.

Nulla molestie ipsum ac sapien interdum eu faucibus eros viverra.

Nulla eu odio nunc. Ut ut libero ut eros adipiscing luctus.

Nunc non nulla odio. Curabitur ac facilisis orci.

Curabitur vitae dui metus, et blandit magna. Donec sollicitudin sodales orci non mollis.

\CountedSection{Lipsum 3}
Morbi lacinia scelerisque odio, sollicitudin tempus erat mattis ut.

In elementum auctor rhoncus. In sit amet lorem a ligula rhoncus accumsan quis non magna.

Vivamus sit amet erat at magna ultricies vulputate. Nunc tortor neque, blandit eu elementum malesuada, iaculis a eros.

Fusce vulputate, elit et iaculis fringilla, orci dui congue justo, at cursus elit velit vitae felis. Duis lacinia aliquam quam, sed vulputate risus porttitor vitae.

Sed dictum lectus eget quam pharetra hendrerit pharetra nibh ultricies. Donec vitae diam purus, a consequat ligula. Donec imperdiet vulputate consequat.

Nunc eleifend dapibus eleifend.

Donec lobortis enim ac quam sagittis fermentum.

Cras vestibulum accumsan nisl, et molestie justo blandit eu. Nunc pretium, tellus sed rutrum euismod, erat quam lacinia est, in convallis nisi ipsum nec dolor. Cras non urna enim.

\CountedSection{Lipsum 4}
Quisque ornare, felis eu tincidunt lacinia, sapien turpis molestie nulla, sed vestibulum massa arcu nec metus.

Phasellus placerat interdum congue.

Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos himenaeos. Nulla ac nibh nec diam rutrum placerat.

Vivamus in imperdiet nisi.

Donec nibh est, vehicula et molestie eu, lobortis in ante. Nullam aliquam orci et justo rhoncus porta.

Aliquam ac sodales purus.

share|improve this question
Would you be able to provide a compilable minimal working example (MWE) that clearly illustrates your problem rather than code snippets? The latter is not very helpful in providing the exact context, while the former will give community members an opportunity to hit the ground running rather than trying to recreate your problem. – Werner Jan 26 '12 at 16:52
AFAIK marginpars are really a type of float. Bad page breaks tend to happen also when there is a large backlog of figure and table floats. Maybe this problem is related? – Michael Palmer Jan 26 '12 at 17:19
@Werner Sorry, of course. I keep forgetting that :/ Added now. – Anton Jan 26 '12 at 19:36
@MichaelPalmer That may very well be related as the problem only seems to show up when there's a lot of short paragraphs. Unfortunately that's what most of my document is. – Anton Jan 26 '12 at 19:37
I don't think it is a robust decision to use marginal notes for paragraph numbering. As Michael mentioned, those are floating but you don't want your paragraph numbers to float. They should be exactly where the paragraph started. You may also run into some "too many unprocessed floats" errors. Finally, if you start using marginal notes as textual elements of your document, everything will break up completely. So I think the \makebox solution is much safer and better. – 5gon12eder Jan 27 '12 at 21:45
up vote 4 down vote accepted

The short answer is that \everypar is definitely not a user command for use in definitions unless you obey the restrictions that LaTeX puts on it (and you fully understand how it is used in the kernel, something which isn't documented very prominentely, but then it is not a user command). So it is a bit of "unsupported input -> arbitrary results". If you look at

\section{foo} \showthe\everypar

then you see that \everyparhas the following definition at this point:

> \if@nobreak \@nobreakfalse \clubpenalty \@M \if@afterindent \else {\setbox \z
@ \lastbox }\fi \else \clubpenalty \@clubpenalty \everypar {}\fi .
l.4 \section{foo} \showthe\everypar

and that means your redefinition of \everypar clobbers all the section handling of the paragraph following it. In particular the switch "@nobreak" was set to true by the section and now it isn't reset with a good number of unexpected side-effects including some of the \marginpar handling ...

So of course one could analyse this in more detail, but ... :-)

share|improve this answer
Thank you for this answer. Adding \@nobreakfalse to the \everypar does infact make it break properly though I will readily admit to not (yet) having a clue as to what this does and that the whole thing is a hack on my part :) – Anton Feb 4 '12 at 19:28

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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