Consider the following MWE:





% using this longtable changes the header from "1 First" to "2 Second":
% \begin{longtable}{ll}
%  bla & blub \\
%  bla & blub
% \end{longtable}



Curiously adding the longtable environment changes the page heading from »1 First« to »2 Second«. Am I missing something obvious? Does anybody know where to look for the cause?

  • Interesting question, but it has nothing to do with koma-script: The behaviour also arises for \documentclass{article}\pagestyle{headings}. I suggest you edit the question/MWE acordingly.
    – lockstep
    May 6, 2012 at 17:09
  • @lockstep Indeed, thanks! I thought I had tested this...
    – cgnieder
    May 6, 2012 at 17:12
  • duplicate (I think) of tex.stackexchange.com/questions/43406/… (or at least I knew I'd suggested that fix before...) May 6, 2012 at 17:17

2 Answers 2


I think it's a bug sorry, there are similar (but different) instances in the bugs database, a workaround is to modify a local copy of longtable around line 402 to lose the vboxing.

%      \vbox

If you let me know if that (a) fixes your real case and/or (b) breaks everything else, that would be useful information....

  • This seems to work. I just tested it with a larger document that uses several longtables. I can't see any issues so far. (I am out of upvotes for the day.. I'll vote tomorrow.)
    – cgnieder
    May 6, 2012 at 17:21
  • 3
    there is a danger that after handing back to the main document output routine that it (if it finds it hard to find a good break point for the next page) breaks the table _before _ the last foot as there are potential break points between the table rows. that's why (a lifetime ago) I left the final section boxed. But it messes up marks set on the last page (or in this small example set before the table) May 6, 2012 at 17:26
  • I see. I'll keep that in mind...
    – cgnieder
    May 6, 2012 at 18:03

Building on David Carlisle's suggestion, here's a solution that doesn't require you to make a local copy of the file longtable.sty. Instead, it utilizes the macro \patchcmd of the etoolbox package. Inserting the following code in the preamble should do the trick.

% The following code should only be used with v. 4.11 [2004/02/01, (DPC)] 
%    of the longtable package. It will probably -- actually, almost 
%    certainly! -- not work with other versions of this package.
% There are four separate occurrences of \vbox in "\LT@output"; 
%    must patch (i.e., eliminate) only the one that follows "\@colht".
\patchcmd{\LT@output}{\@colht \vbox}{\@colht}{}{} 
  • I think patching is the thing to do when extending package functionality, but if you are fixing a bug, then it's probably safer (and a better test of any potential official fix) to modify the package (and modify the ProvidePackage line to note the package has been modified) apart from anything else, I am not sure this is the best fix, but whatever the fix is, it is likely to make that patch fail to apply so the document would stop working if longtable gets updated. May 6, 2012 at 19:12
  • 1
    I absolutely agree with you. My reason for providing the code for the \patchcmd route was to help people -- I suspect there are probably more than just a handful of them -- who don't know how to "modify a local copy of longtable" (and comment out the instruction on l. 402). To be sure, all of the caveats you've expressed about the perils of the bug fix using your method apply equally well to "my" method. I'll add some comments to the code to alert users that this patch will fail if and when the longtable package gets updated.
    – Mico
    May 6, 2012 at 19:46

You must log in to answer this question.

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