With the beamer class, however, I don't get the horizontal alignment correct: There is some additional vertical space above the itemize environment, and I don't manage to remove it. (Is it some \topsep or \partopsep? I tried the package enumitem, but this only made things worse.)

What is a good way to solve this problem? Are there fixes for the itemize, or should I use a totally different approach?

EDIT1:

OK, with Juan's help I have father pinpointed the problem. Let me first elaborate on what the remaining alignment problem is: Yes, Juan, you're right, at the first sight it seems to be pixel perfect. But if you really magnify (3000% or so), then you see that it isn't. It gets worse and much easier visible if you change "1st question" to "1st question $(*)$". You get perfect alignment if you change "1st question" to "Questions:" (really helpful ...). So the contents of the first \item really matters.

I've checked with article class; there the alignment is 100% perfect. A very funny thing: In this case you mustn't use the \vspace{0pt} hack since it destroys the desired alignment.

EDIT2:

Juan's answer provides a great fix for my problem, but to me it doesn't seem like the final solution. Is this strange behaviour of the beamer class a bug or a feature?

What is the purpose of using a minipage here? Seems like the first one can be handled by LaTeX's \makebox. The second one seems like a good candidate for \parbox. That said, I can't get beamer's itemize to behave in a sane way, no matter what I do.
–
TH.Sep 22 '10 at 18:18

Good question. This is just the way I'm doing it, without thinking why. It's never clear to me what the difference between a \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 VogtSep 22 '10 at 18:52

minipage 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 a minipage. 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

Have you tried\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 VogtSep 23 '10 at 7:23

4 Answers
4

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\vtopbox] 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 \hboxes), 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 \kerns, 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.

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

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.

Note the added \vspace at the beginning of the first minipage. The problem isn't really a space before the itemize (you can see this by wrapping each minipage on an \fbox), but somehow beamer gets different “tops” for the minipage with the itemize and the one starting with a regular paragraph, making them look misaligned. Maybe someone with more experience in beamer's internals can figure out what is going on?

Edit: The above solution almost works, but not quite. It seems to be bitten by what I call “Beamer's vertical alignment problem”. The problem seems to be that, in some situations, beamer aligns the absolute “tops” of pieces of text. For example the tops of “aaa” and “ttt” lie at very different levels, and if one aligns the tops, the baselines get misaligned. A solution is to use \vphantom and fake the “top” of each piece of text to a common maximum. For example, the following seems to work.

Just found a fix and edited the answer!
–
Juan A. NavarroSep 21 '10 at 14:58

The effect of the \vspace is a miracle to me. (Where did you get the idea?) It seems, however, that this almost solves the problem but not quite: The alignment is a lot better, but not perfect. The tip with the \fbox was great since this really helps pinpointing the problem. It seems that with your "hack" the fboxes are aligned, but the itemize is still causing a bit of trouble.
–
Hendrik VogtSep 21 '10 at 15:56

Can you elaborate on what's the problem? on my screen+pdf viewer the alignment seems to be pixel perfect. Btw, I just "stumbled" upon the solution a bit by trial and error, I was fiddling with the alignments trying to add \vspace to shift things up/down.
–
Juan A. NavarroSep 21 '10 at 16:26

I just encountered this problem only with a slight variant. I didn't have two minipages that I wanted to line up, but one minipage that I wanted to line up with ordinary text. Thus the sample was text\begin{minipage}[t]{3cm}\begin{itemize}\item text\end{itemize}\end{minipage}. Using \fbox, I could see that the top of the minipage was being aligned with the midpoint of the text. Juan's answer doesn't apply because that messes with the first minipage, which doesn't exist in my scenario. Also, Juan's answer works by pushing the first minipage down to match the second, rather than bringing the second up to match the first.

Here's my solution. I don't know how robust it is. It works by noting that the problem goes away if the minipage doesn't start with something like an itemize environment. So we start with something else to get the external alignment correct. But then that changes the internal alignment so we have to remove that. But since we have full control over the "something else" we started with, we know exactly how much to remove.

The implementation is simply to put \vphantom{}\vskip-\baselineskip at the start of the minipage. It is possible to put something substantial in the \vphantom. What this does is change TeX's opinion of the height of the minipage. This might be desirable if the contents of the minipage has greater height (above the baseline) than the surrounding text.

You can remove the \fboxes and the rules and change the letters to see that this is reasonably robust, but I don't know what other nightmare combinations should be used to test against.

This even seems to work if the minipage doesn't start with an itemize so, with the same qualifiers above, one could redefine the minipage environment to insert this code automatically (I guess that the \vskip puts in in vertical mode so the \vphantom\vskip-\baselineskip some text works out as two paragraphs but the second shifted to be placed on top of the first).

In article mode, this (naturally) is wrong. So it should be combined with some sort of \ifclassisbeamerbutbeamerarticlenotloaded conditional. Actually, \mode<presentation> would do!

It took a while :-) but finally I read your answer in detail. You're right, the disadvantage of Juan's answer is that the first minipage is pushed down, too. For "usual" heights of the first line in the itemize, your solution works great. But I don't know what to do if that line contains something of larger height, like \rule{1pt}{4ex}. Adding this to the \vphantom doesn't help ...
–
Hendrik VogtSep 29 '12 at 10:58

As I wrote, I already tried enumitem: What I meant by "only made things worse" is that it doesn't remove the space, but instead it removes the bullets of the itemize environment ...
–
Hendrik VogtSep 21 '10 at 14:23

@Hendrik you can get back the bullets of the itemize environment by writing it as \begin{itemize}[label=\textbullet]
–
Pranav MMay 24 '13 at 9:45