multicols not wrapping to 2nd column properly?

Question

This question led to a new feature in a package:
multicol

I am having problem with multicol package, I created a sample demo to show it.

When I put 3 minipages of certain height in the multicol it puts 2 of the boxes on the first column, but the 2nd box is too big to fit that column (overflows the page) and should've been moved to the 2nd column. LateX even outputs the message Overfull \vbox (145.52644pt too high) has occurred while \output is active.

But if I go change the height of the 2nd box to 40em, it would work great, and also if I use unbalanced columns (multicols*) then it also works great, but I need balancing columns and I need it to handle columns automatically.

\documentclass[12pt]{article}
\usepackage[paperwidth=8.5in, paperheight=11.0in, right=.25in,left=.25in,top=.75in,bottom=0.75in]{geometry}
\usepackage{multicol}

\newcommand{\drawbox}[1]
{
    % Draws a simple box given the height
    \noindent\fbox{%
        \begin{minipage}{0.9\linewidth}%
            \hfill \vspace{#1}%
        \end{minipage}
    } \\
}

\begin{document}
    \begin{multicols}{2}
        \drawbox{40em}

        % This box is too big to fit in the fist column, but would work great in the second colum
        \drawbox{30em} 
        \drawbox{40em}
    \end{multicols}
\end{document}

Answer 1

This is a mixture of very unsuitable input ;-) and a deficiency of multicol. Multicol was originally designed for text balancing and the algorithm makes some assumptions based on this. One of the assumption is that the galley material to cut the columns from has a suitable number of breakpoints to allow for this and inparticular to allow for balancing. Now your example has two properties:

• there are very few break points
• the material nevertheless would fit onto a single page (if it could be broken). The latter can be see when one replaces the second \drawbox by 2 boxes with 15em each. Then suddenly everything balances nicely and still fits onto the page.

Algorithm

Now the balancing algorithm roughly works as follows:

• It measures the whole galley to balance and from that value it deduces a start value for cutting columns of. That start point can be influenced, but that would not help here.
• It then cuts off the columns and the last one receives all leftover material. It then checks if the height of the last column is higher than that of the first column and if so rejects the solution.
• It also rejects the current trial if any of the columns have a very high badness (customizable).
• It also rejects the trial if there have been columnbreaks that were not honored.
• If the trial was successful the value found will be used, not it will be increased by one point and the algorithm repeats.

If the final value is larger than the available space then multicol attempts to recover by squezing all columns into the available space. With normal text columns that is likely to succeed, as there is usually some shrinkability on the page and with enough breakpoints in the galley the ammount of excess is not likely to be high either.

Applied to this example

On this examble this approach of course fails as the algorithm loops until the column height is large enough to hold two boxes in the first column (smaller cutting values will always make the second column too large). And by the time this happens the column size is so far off from the available space that no squeezing (even if there would be anything to squeeze) would help.

A manual solution to resolve this problem would be to enter an explicit page breaks into the source, i.e.,

\drawbox{30em} \pagebreak

so that multicol would stop gathering data and this would be then produced as a normal page. Hower this is certainly labor intensive and would need changing whenever the document would change.

An alternative would be to use multicols* but that again has the big drawback that then you don't have balancing at all and thus any text following the third \drawbox would then be on the next page and not (as it could ) continue on the same.

Multicol deficiency (?)

Now one can argue that if multicol does its balancing and finds a solution like the one in the above example it should really reject that one too. But what should it then do?

One possibility would be to conclude that balancing wasn't the right approach after all and instead first cuts another "normal" page and then does its balancing on the remaining material. Again for this particular example this would work pretty well. However, if you look at the following example the result would be at least questionable:

\documentclass{article}

\usepackage[balancingshow]{multicol}

\setlength\textheight{5\baselineskip}

\begin{document}
\begin{multicols}{2}
1\\2\\3\\4\\5\\6

1\\2\\3\\4\\5\\6
\end{multicols}
\end{document}

With the current algorithm this will result in one (slightly overfull) page with six lines in each column, while with an algorithm that rejects such balancing it would result in 2 pages with a single line in every column on the second page.

So right now I'm not sure what the best approach is here. Perhaps this calls for another parameter such as \balancingoverflow that holds the amount that the columns in balancing are allowed to get "overfull".

In any case, I do have a proto-type written last night that does this reject and if anybody wants to play around with it, drop me an email at my "latex-project.org" address.

Update

I have decided to implement this new feature using the parameter \maxbalancingoverflow with a default of 12pt. The new version also corrects the algorithm for right to left typesetting. It can be obtained from the LaTeX2e SVN sources: multicol.dtx for those who want to test it out right now. With the next release of LaTeX2e it will then show up on CTAN.

As of May 2014 CTAN has a new LaTeX release that contains this feature.

Answer 2

The obvious solution is not trying to balance the columns, i.e. use multicols* instead of multicols. This is probably not what you want.

The multicolumn package tries very hard to solve most problems with multicolum typesetting in LaTeX, but it's still a clutch as LaTeX wasn't designed for these things. If you want a better solution, you should switch to ConTeXt.

And of course you could file this as a bug with the LaTeX project, but I doubt that Frank will be very happy.

Answer 3

Can I make a case for unbalanced columns if you want to have multiple minipages in a 2-column workflow?

With multicols* the columns on the last page are not balanced but difficulties can still arise on other pages.

Using \raggedcolumns with multicols allows the columns on every page to be unbalanced.

IMHO, this second option gives a good 'look' to individual items without manual or detailed intervention (e.g. to stop individual text blocks being unduly vertically stretched by adjusting TeX settings or moving items round to try and improve the fit.) I use a structure like this to produce a weekly 2-column document with multiple short or medium items that might include headlines, subheads, multiple paragraphs and illustrations. I do not want any individual article to split over a column or over a page. I did experiment with balanced columns but found this was time-consuming and had a tendency to be somewhat messy-looking.

If the blocks of material are unordered and at least some are short then you may be able to move things around to allow the typesetting engine to make adjustments to produce balanced columns but the result even then can be disappointing. Allowing ragged columns throughout allows ordering of items (e.g. date order for diary items or in order of importance or to determine which articles get the 'best' positions) and only gross imbalances need manual intervention (e.g. three consecutive articles each longer than half a column leaving at much of at least two consecutive columns blank). It also speeds workflow allowing me to concentrate on the content and TeX to produce attractive typeset output.