overlayarea + onlyenv vs. includegraphics = weird behavior

[James Harkins]

I was about to ask this on tex.stackexchange, but it seems it's more of a bug than a usage question. TexLive 2013 distro, Ubuntu 12.04.

I am trying to replace images in successive slides, with text underneath. The images are all the same size and should appear in the consistent position from frame to frame. This looks like a job for overlayarea, but... the first overlay is correctly positioned and all subsequent ones are too low.

I have the following structure in LaTeX:

- \begin{frame}
    - \begin{overlayarea}
        - \begin{onlyenv}<1>
            - \begin{center}
                - \includegraphics
            - \end{center}
            - \begin{block}
                - Text...
            - \end{block}
        - \end{onlyenv}
        - \begin{onlyenv}<2>
            - \begin{center}
                - \includegraphics
            - \end{center}
            - \begin{block}
                - Text...
            - \end{block}
        - \end{onlyenv}
    - \end{overlayarea}
- \end{frame}

I assumed in this that the onlyenv with overlay spec <2> would begin at the same vertical position, but it's much lower.

As another test, I split up the overlay areas into two: one just tall enough for the graphics, and the second reserving the rest of the space for the text. With this arrangement, the text placement is consistent -- but the graphic for overlay 2 is still too low! In fact, it crashes into the text.

I also tried replacing \begin{onlyenv} ... \end{onlyenv} with a simple \only, and... the problem went away. So it seems there's a bug with onlyenv. The problem is that I'm automatically generating LaTeX from the org-mode exporter. It's easy to generate onlyenv, but really hard to produce \only this way.

My questions, then:

- Is it a known issue? If yes, has it been fixed (or what's the prognosis for a fix)?

- If it won't be fixed, will it be documented that onlyenv seems to have difficulty with includegraphics?

Thanks in advance (as I've been fighting this issue for a couple of years now),
hjh

%% TEST LATEX CODE
%% see attachment for the includegraphics target
%% Please compile with xelatex or pdflatex
% Created 2015-05-02 Sat 18:12
\documentclass[presentation]{beamer}
\usepackage[T1]{fontenc}
\usepackage{fixltx2e}
\usepackage{graphicx}
\usepackage{longtable}
\usepackage{float}
\usepackage{wrapfig}
\usepackage{rotating}
\usepackage[normalem]{ulem}
\usepackage{amsmath}
\usepackage{textcomp}
\usepackage{marvosym}
\usepackage{wasysym}
\usepackage{amssymb}
\usepackage[hidelinks]{hyperref}

\begin{document}

\begin{frame}[label=sec-3-4]{Overview of Kontakt design}
\begin{overlayarea}{1.0\textwidth}{3.0in}
\begin{onlyenv}<1>
\begin{center}
\setlength\fboxsep{0pt}
\setlength\fboxrule{0.5pt}
\fbox{\includegraphics[height=1.7in]{./img/kontakt-chart-01-layout.pdf}}
\end{center}
\begin{block}{The basic layout: Several zones within one group.}
\begin{itemize}
\item Each zone covers its own range of MIDI keys and velocities.
\item An instrument can have several groups.
\end{itemize}
\end{block}
\end{onlyenv}
\begin{onlyenv}<2>
\begin{center}
%% FOR SIMPLICITY I've replaced graphic 02 with graphic 01
%% (One email attachment rather than two)
\fbox{\includegraphics[height=1.7in]{./img/kontakt-chart-01-layout.pdf}}
\end{center}
\begin{block}{A MIDI note comes in.}
\begin{itemize}
\item It has a specific note number and velocity.
\item Dummy item so that we have two.
\end{itemize}
\end{block}
\end{onlyenv}

\end{overlayarea}
\end{frame}

\end{document}

[James Harkins]

On Saturday, May 2, 2015 at 7:12:33 PM UTC+8, James Harkins wrote:

I was about to ask this on tex.stackexchange, but it seems it's more of a bug than a usage question. TexLive 2013 distro, Ubuntu 12.04.

I am trying to replace images in successive slides, with text underneath. The images are all the same size and should appear in the consistent position from frame to frame. This looks like a job for overlayarea, but... the first overlay is correctly positioned and all subsequent ones are too low.

<snip>

I also tried replacing \begin{onlyenv} ... \end{onlyenv} with a simple \only, and... the problem went away. So it seems there's a bug with onlyenv. The problem is that I'm automatically generating LaTeX from the org-mode exporter. It's easy to generate onlyenv, but really hard to produce \only this way.

The urgency is diminished -- I found that it's much easier than I thought to change "\begin{onlyenv}<overlay> ... \end{onlyenv}" into "\only<overlay>{ ... }" -- so I can generate my slides properly now.

However -- it remains true that onlyenv is not a reliable replacement for \only{} in all cases, at least in TexLive 2013.

hjh