# placing of floats referenced with varioref

In my text I use \vref{<label>} from the varioref package for referencing figures and tables. In most circumstances this works satisfactory. Exceptions are cases, when in a text line \vref appears near the end of the line such that for example Fig. 1 is placed in one line and on the next page goes to the next line, where a float with attribute [h] is placed. In that case, that below line with Fig. 1 leaves enough room for the float, if the reference is only Fig. 1 and therefore accommodates in one line. If the float is not placed here (below line with reference) but always pushed to the next page and reference is expanded into two lines.

It seem that this happen because the algorithm of varioref starts always with the assumption that the float is placed on a different page as is \vref. I wonder if there is a way to convince the varioref to start with the assumption that the float will be placed in the same page as \vref and if this is not true to expand \vref with terms on the next page or on the page <num> in the second (or third) run of latex? Or exists some equivalent package with similar features as varioref, which works as I wish?

Temporary I help myself that after compilation in the described cases I manually change \vref to \ref. But this is based on guessing and it is contrary to the (La)TeX "mission" (take care on text layout).

Edit MWE (based on answer of David Carlisle), which show behavior of varioref is:

% usual I use memoir package
\documentclass{memoir}
\renewcommand{\thefigure}{\thesection-\arabic{figure}}

\usepackage{varioref}
% my shortcuts for referencing
\renewcommand{\fref}[1]{(\figurename~\ref{#1})}
\newcommand{\vfref}[1]{(\figurename~\vref{#1})}
\begin{document}
\setcounter{chapter}{11}
\setcounter{section}{12}
\setcounter{figure}{122}

abc\\abc\\abc\\

aaa aaa aaa aaa aaa aaa aaa aaa aaa aa
%    ref produces: \fref{figure}
vref produces: \vfref{figure}
\begin{figure}[h]\centering
\fbox{\parbox[b][5ex][c]{0.5\hsize}{a figure}}
\caption{My figure}
\label{figure}
\end{figure}
\end{document}


if I un-comment line with ''ref'' and comment line with ''vref'' than the figure appear on the same page as it is reference on it, contrary the figure is moved on the next page

• varioref is supposed to detect same-page references, if you have a case where that is not working it would be helpful to make a small complete example document that demonstrates the problem and add it to the question. – David Carlisle Nov 2 '14 at 14:02
• There are a couple of possibilities on how to interpret your comments above leading to either a bug or a limitation or even a misunderstanding on your part. Please extend your question with a selfcontained complete example to better understand the situation here. I can think of a couple of case where things might get complicated (or even fail) for example if your reference surround the H float but it is pointless to guess. – Frank Mittelbach Nov 2 '14 at 20:26

The only way I can reproduce this is to edit the file between runs.

\documentclass{article}

\usepackage{varioref}

\begin{document}

abc\\abc\\abc\\abc%\\ABC

aaa aaaa aaaa aaa aaa
aaa aaaa aaaa aaa aaa
vref produces: Figure \vref{zz}.

aaaa\\zzz
\begin{figure}[ht]
\fbox{XXXX}

\caption{fff\label{zz}}
\end{figure}

bbb

\end{document}


If you uncomment ABC the figure goes to page 2 as shown in the first image, varioref picks that up and adds "on the next page" if you then comment out the \\ABC varioref doesn't notice the figure is now only on the next page because of its added text, so it keeps adding it as shown in the second image.

However if you delete the .aux file and run latex twice more, varioref computes everything for the new figure position with a same-page reference.

So to be sure, after edits delete any old .aux file before running latex until the references are stable.

• David Carlisle, in my text for referencing i use the following command: \newcommand\vfref[1]{(\figurename~\vref{#1}), if this is important. Regarding to necessary manual manipulating, your solution is similar to mine :_), of course on different way. This is not big deal (manual manipulation), if you have only few such a cases and doesn't make any revision of written text. Otherwise, the "automatized" procedure (as part of package algorithm) is highly desired. In this sense, my question is actually feature request. – Zarko Nov 2 '14 at 17:05
• @Zarko no mine is not really manual manipulation, you should clean the aux files and rebuild after an edit, otherwise if you come back to the document later when you only have the tex source you will get a different result. if your automated procedure is remove aux file, latex latex latex, then the problem does not arise. I'm not sure that it would be possible to detect this within the same latex run latex cross referencing always uses the values stored on the previous run, so they may always be wrong if the file has been edited – David Carlisle Nov 2 '14 at 17:16
• Now I see a differences between your approach and mine. In further I will use your suggestion. Thank you. – Zarko Nov 3 '14 at 17:06

It is indeed possible that varioref generates sub-optimal results in special circumstances but your MWE is actually not an example of this. If you run this MWE starting without any .aux file then everything comes out fine, i.e., you first get

Basically your assumtion that varioref starts out with the assumption that the float is placed on a "different" page is wrong. Instead it starts out with no knowledge about the float and as a result it just produces the famous ?? as a reference. And this is "nearly" as short as it can get. Thus the real reference with normally be longer.

So in short your MWE can't produce the problem you describe unless you do edit things and start from an existing .aux that is representing a situation with 2 pages.

Now there is the danger that the real reference is even shorter that ?? and it might have been better to generate an unknown reference showing only a single ?, but that has other issues as it doesn't really stand out in proof reading. So there are scenarios (with small probability) that can result in a sub-optimal solution.

There are also others that involve several references that result in moving text to different places. The one that I came up with is this one:

\documentclass{article}

\usepackage{varioref}

\setlength\textheight{9.8\baselineskip}
\setlength\textwidth{2.9cm}

\begin{document}

\section{Foo}

In theory this document could come out with 2 pages only. But the
delayed processing makes it 3.

Ref to fig1:  \vref{fig1}.  % this pushes things out

So test again to see \vref{fig1} and and we also reference
figure two: \vref{fig2}

\begin{figure}[t]
\caption{fig1}\label{fig1}
\end{figure}

\begin{figure}[h]
This one is bigger
\caption{fig2}\label{fig2}
\end{figure}

\end{document}


If you run this and look at page 2 you see

that is the first 2 references are fully on page 1 (because they are short, i.e., ??).

Next time around, however we get

because first references pushes things downwards. Worse the ref to fig1 was on page 1 last time so now the string "on the next page" is added (which was right but is wrong now). This extra material pushes figure 2 (temporarily) to page 3.

Next time around the reference to fig 1 gets corrected (and the string "on the next page" vanishes) but now the ref to fig2 knows this figures is on page 3 and so this time it adds "on the following page" which takes up the space just freed:

This is now both correct and stable (but unfortunately not optimal). Basically it is a local optimum not the global one, but I fear that is something that is simply in the nature of the algorithm and not something you can easily work around (if at all).

After all:

• the generated text length varies in a non-linear fashion with the position of the target
• that in turn may change the generated text (as the target position is changed by inserted generated texts
• so you have the situation that both call-outs can move (any later ones are affected by generated text earlier on) but also the callback relationship that this in turn affects what needs to be generated as text.

So a local maximum seems to be the best you can hope for, in fact it is not too difficult to generated an "impossible" document, i.e., one that is changing in a way that it is always wrong.