LaTeX's failure with floats

It's probably fairly uncontroversial to say that floats are one of the main areas where LaTeX performs poorly in comparison to WYSIWYG editors. The basic complaint is that floats just don't go where we want them.

To compensate for this, people often use the h float specifier or H from the float package to say, “place the figure here!” This is often a poor approach since there's no real idea of where here really is. This leads to moving the code around between paragraphs, trying to find a reasonable place to put it. Since this is a bad idea, I'm not going to focus on it. Instead, I'm going to talk about real floating material.

Part of the problem is that TeX produces output one page at a time. Once a page is finished, it is shipped out (i.e., written to the dvi or pdf) and not touched again. What this means for LaTeX is that by the time it has seen the \begin{figure} (or other floating material), it has already finished with all of the pages before it. So what it does is it performs a complicated interaction with the output routine which will try to place the figure (subject to the specifiers) on the current page. If that fails, it gets stuffed onto a defer list to be inserted later.

Often, what we really want is for the image to go onto the previous page since that leads to better overall placement. But since LaTeX cannot handle that, we're forced to move the image code ourselves, just like we had to do with the H specifier.

One partial solution is to put each float in a separate file, floatfoo.tex and then move \input{floatfoo} around until a reasonable placement is found. This is not entirely satisfactory since we still have this guess and check procedure.

What I would like is a solution that allows the author to specify a page number (and position) and have the float placed there, if at all possible. I haven't fully thought through what I'd like in an interface, so here are some thoughts about requirements and challenges.

• The interface should work with twocolumn documents at the very least and it would be better if it supported the multicol package. Something like

  \begin{figure}[page=4,column=2,position=tb]

  might be nice.
• There are tokenization issues so it is probably not acceptable to tokenize the body of the float, store it somewhere, and then reproduce it when needed since category codes will be assigned at tokenization time. This almost certainly requires writing the output to another file.
• One idea is to use the filecontents environment to write the body of the figure to separate file with appropriate \if... guards. I'm envisioning something like

  \begin{figure}[page=4,position=tb]
      \centering
      \includegraphics{foo}
      \caption{bar}
      \label{fig:foo}
  \end{figure}

  being written to \jobname.figs as

  \ifnum4=\count0
  \begin{figure}[tb]
      \centering
      \includegraphics{foo}
      \caption{bar}
      \label{fig:foo}
  \end{figure}
  \endif

  Then, for each page, \jobname.figs is \input in a manner similar to \afterpage or \AtBeginPage. This would need something extra for twocolumn documents.
• There's the question of trying to keep figures in order if some are specified with particular page requirements and others are not.
• There's an issue if a float depends on a macro being defined but the page specifier puts it before the definition. I don't see how to get around that.
• There's an issue with trying to work with other floating environments such as the excellent lstlisting from the listings package.

I'm sure there are more issues I haven't considered. This does seem doable though.