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} \addtolength\textheight{-35\baselineskip} \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


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





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





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.

placing of floats referenced with varioref

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

placing of floats referenced with varioref

and if you re-run (as requested) you get the best possible result, i.e.,

placing of floats referenced with varioref

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:






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}


This one is bigger


If you run this and look at page 2 you see

placing of floats referenced with varioref

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

Next time around, however we get

placing of floats referenced with varioref

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:

placing of floats referenced with varioref

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.

Category: floats Time: 2014-11-02 Views: 1

Related post

iOS development

Android development

Python development

JAVA development

Development language

PHP development

Ruby development


Front-end development


development tools

Open Platform

Javascript development

.NET development

cloud computing


Copyright (C), All Rights Reserved.

processed in 0.170 (s). 12 q(s)