It took me two years :-)
but now I know what's happening and how to fix it. The main point is that \begin{minipage}[t]
creates a \vtop
box, which is responsible for alignment at the top. Now one needs to read the TeXbook, bottom of page 81:
The final height x [of the \vtop
box] is defined to be zero unless the very first item inside the new vbox is a box; in the latter case, x is the height of that box.
This means: If the minipage starts with some text (possibly broken into lines, which TeX has put into \hbox
es), then the vertical alignment of the \vtop
box doesn't take place at the very top of the box but at the baseline of the first line of text in the box. And this is exactly what one wants here, alignment of the baselines (red):

However, if the minipage does not start with a box, but e.g. with a color change, then one doesn't obtain alignment of the baselines; instead, the baseline of the word "Questions" is aligned with the top of the second minipage, like this:

How to fix the problem
According to the above explanation of the behavior of \vtop
, the solution will be to make sure that the very first item inside the \vtop
box is the \hbox
containing the first line of text. Thus, we have to avoid any \kern
s, color changes etc. at the top of the minipage. In the code below I roughly explain the main ideas. The code is tested with various combinations of overlay commands and manual color changes.
\documentclass{beamer}
\makeatletter
\def\beamer@callorigitem{%
\@ifnextchar[
\beamer@@callorigitem
{\beamer@origitem
\if@minipage\else
\kern0pt % don't put the \kern at the top of a \minipage
\fi
\ignorespaces
}%
}
\newcommand*\if@minipage@and@vmode[2]{%
\let\mini@vmode 0%
\if@minipage\ifvmode
\let\mini@vmode 1%
\fi\fi
\if\mini@vmode 1 #1\else #2\fi
}
% Redefine \beamerorig@set@color, \pgfsys@begininvisible and \pgfsys@endinvisible
% such that they don't act at the top of a \minipage;
% instead save the corresponding commands in \set@minipage@color ...
\def\set@minipage@color{}%
\let\save@beamerorig@set@color\beamerorig@set@color
\def\beamerorig@set@color{%
\if@minipage@and@vmode{%
\begingroup
\def\reset@color{\relax}%
\xdef\addto@minipage@color{\save@beamerorig@set@color}%
\endgroup
\expandafter\g@addto@macro\expandafter\set@minipage@color
\expandafter{\addto@minipage@color}%
\aftergroup\reset@color
}{%
\save@beamerorig@set@color
}%
}
\let\save@pgfsys@begininvisible\pgfsys@begininvisible
\let\save@pgfsys@endinvisible\pgfsys@endinvisible
\def\pgfsys@begininvisible{%
\if@minipage@and@vmode
{\g@addto@macro\set@minipage@color{\save@pgfsys@begininvisible}}
{\save@pgfsys@begininvisible}%
}
\def\pgfsys@endinvisible{%
\if@minipage@and@vmode
{\g@addto@macro\set@minipage@color{\save@pgfsys@endinvisible}}
{\save@pgfsys@endinvisible}%
}
% ... and execute them at the beginning of the first paragraph of the minipage
% (where \everypar issues \@minipagefalse).
\let\save@minipagefalse\@minipagefalse
\def\@minipagefalse{%
\set@minipage@color
\gdef\set@minipage@color{}%
\save@minipagefalse
}
\makeatother
\begin{document}
\begin{frame}
\begin{minipage}[t]{1.6cm}
Questions:
\end{minipage}\nobreak
\begin{minipage}[t]{9cm}
\begin{itemize}
\item 1st question;
\item 2nd question.
\end{itemize}
\end{minipage}
\end{frame}
\end{document}
If one compiles this with
\tracingoutput=2
\showboxbreadth=\maxdimen \showboxdepth=\maxdimen
in the preamble, then in the log file one finds the lines
.....\vbox(7.43904+18.72917)x256.0748
......\hbox(7.43904+2.12917)x234.17474, glue set 87.88736fil, shifted 21.90005
This tells that the second minipage is a \vbox
with a height of 7.43904pt
and a depth of 18.72917
, and that the first item inside the \vbox
is an \hbox
. Without my redefinitions of \beamer@callorigitem
, \beamerorig@set@color
, \pgfsys@begininvisible
and \pgfsys@endinvisible
, one will find
.....\vbox(0.0+26.16821)x256.0748
......\pdfcolorstack 0 push {0 g 0 G}
......\kern 0.0
in the log file instead. This means that the second minipage is a \vbox
with height 0pt
(and one sees the color change and the \kern
responsible for this!).
How to "officially" fix it
The problem isn't really beamer
specific, except for the \kern0pt
in \beamer@callorigitem
from beamerbaseoverlay.sty
. One gets the same misalignment with the article
document class if one uses, e.g., \color{red}
at the top of the minipage. The changes to \beamerorig@set@color
(which is \let
to \set@color
by beamer
) and to \@minipagefalse
would best fit into the xcolor
package; the changes to \pgfsys@begininvisible
and \pgfsys@endinvisible
should go to pgfsys.code.tex
.
\makebox
. The second one seems like a good candidate for\parbox
. That said, I can't get beamer'sitemize
to behave in a sane way, no matter what I do. – TH. Sep 22 '10 at 18:18\parbox
and a minipage is. Using minipage for both is just that I like it to be parallel, I guess. I'm quite undereducated in what the "correct" LaTeX way of doing things is. – Hendrik Vogt Sep 22 '10 at 18:52minipage
seems to be people's go to for give me a box of width x. It's overkill and breaks things like footnotes. Most of the time, if you want a horizontal box of width x, you can use\makebox
or simply\hbox to x
. If you want a vertical box of width x, you can use a\parbox
(or a\vbox
or\vtop
, but that tends to take more work to get everything correct). I have never used aminipage
. I'm sure there is a situation that requires it, but I think that requirement is far less common than its use. – TH. Sep 22 '10 at 20:18\makebox
here? I don't get horizontal alignment with it. As for\parbox
, this does work, but it needs the same fixes that Juan provided below. – Hendrik Vogt Sep 23 '10 at 7:23