# Centering cells of a tabular column using m{}

I want to use a tabular to list some headlines, that might be quite long or contain linebreaks. The first column is kind of an Index or Key for the second columns content, so i would like to (vertically) center it (and i'll add \midrules for readability). To achieve the centering i included the array-package with its column definition m{2.5em}. The remaining two columns have fixed widths, too. But - as in the following MWE - the first column is somehow vertically placed top or bottom but not centered.

\documentclass[a4paper,div=calc]{scrartcl}
\usepackage[utf8]{inputenc}
\usepackage{array,booktabs,calc}
\begin{document}
\begin{tabular}{>{\raggedleft}m{2.5em}b{.5\textwidth-6\tabcolsep-8em}p{5.5em}}%
\toprule\textbf{\#}&\textbf{Name}&\textbf{Notes}\\\midrule%
A &
Lorem ipsum dolor sit amet, consectetur adipisici elit&\\
B & \begin{minipage}[t]{.5\textwidth-6\tabcolsep-8em}
An\\even\\higher\\row\\with\\linebreaks
\end{minipage}&\\
2 & Short Entry &
\\\bottomrule
\end{tabular}
\end{document}


And here's how it looks, as you can see, the first column is not vertically centered (i know in this quick MWE the minipage does not have enough space below).

Any ideas?

-
possibly similar to this question about tables with multiple lines in some cells; an answer i just posted there addresses much the same situation. although it doesn't use m{} or booktabs, it does address vertical centering, and top and bottom clearance with array. –  barbara beeton Jan 9 '12 at 22:40
You might look at this answers about differently vertically aligned cells –  egreg Jan 9 '12 at 23:14
@barbarabeeton i didn't get your example to work, but i think it is also a little bit too static in it's use of heights. –  Ronny Jan 11 '12 at 6:59
@egreg thanks fot the hint, i haven't understood the finalcell-command yet, but i was able to adapt it to my situation (well removing one argument...) and it works. After i had applied it to my first cell (of the 2nd column) even the B got centered. So it seems, the reason for the broken m-definition of the first column is occurs, if the second column produces an automomatic linebreak. Thanks for the hint, could you post that as an answer? –  Ronny Jan 11 '12 at 7:00
It may be a bug in the array package. If I change the b placement to m, both the A and the B are aligned to the centre. –  Marc van Dongen Jan 11 '12 at 7:19

applying the method used in an answer to this question to the original example, here is an approach that gives an improved result.

\documentclass[a4paper,div=calc]{scrartcl}
\usepackage[utf8]{inputenc}
\usepackage{array,booktabs,calc}
\newdimen{\lcellwd}
\newcommand{\lcell}[2][\lcellwd]{%
$\vcenter{\hsize#1\baselineskip11pt\vspace*{3pt}\raggedright#2\strut\par}$}
\setlength{\extrarowheight}{1pt}
\begin{document}
\setlength{\lcellwd}{.5\textwidth-6\tabcolsep-8em}
\begin{tabular}{>{\raggedleft}m{2.5em}b{.5\textwidth-6\tabcolsep-8em}p{5.5em}}%
\toprule\textbf{\#}&\textbf{Name}&\textbf{Notes}\\\midrule%
A &
\lcell{Lorem ipsum dolor sit amet, consectetur adipisici elit}&\\
B & \lcell{%
An\\even\\higher\\row\\with\\linebreaks}&\\
2 & Short Entry\strut &
\\\bottomrule
\end{tabular}
\end{document}


EDIT: by moving the \baselineskip instruction to just before \par in the definition of \lcell it is possible to introduce a variable that can be set externally:

\newlength{\lcbaseline}
\setlength{\lcbaseline}{11pt}
\newcommand{\lcell}[2][\lcellwd]{%
$\vcenter{\hsize#1\vspace*{3pt}\raggedright#2\strut\baselineskip\lcbaseline\par}$}


this will adjust the baselines of continuous text, as in group "A", since the baselines currently in force are used when a paragraph is "wrapped". however, it breaks down when \\ is used, and i haven't figured out where \\ "freezes" the current baseline value. using \break instead of \\ does produce the adjusted baselines, but it isn't very latexy; including the \baselineskip instruction in two places would overcome that problem, but it's inelegant.

-
Your solution definetly works, but the thing i noticed is, that the 2 is - just a little bit - too low. And the one thing i don't understand is: I thought your solution is quite static (and fixed to one font size) due to the 11pt and 3pt spaces you insert. But it isn't. That's fascinating, can you explain, why you choose these values? –  Ronny Jan 12 '12 at 7:30
@Ronny -- the 2 is lower than the "name" entry because of the \strut. i added the strut to make sure there would be uniform visual clearance above and below entries in the "name" column. but the 2 has no descender; adding a strut there would ensure the same baseline. as for the spacing values i chose, they are based on experimentation with different sized text, at 9-11pt. (i also defined a \slcell for 8pt or smaller text, with \baselineskip 9.5pt.) when they all looked acceptable to me, i "froze" the values. –  barbara beeton Jan 12 '12 at 15:08
thanks for your explanation. I tried your solution for 14pt (just out of curiosity) and it looked not that nice to me. But it may depend on personal preferences, which way to go; i prefer a more general way using e.g. the way i presented and setting spaces to more general values (as \cmidrulespace font booktabs). And my solution does not need the \strut to align the first column. –  Ronny Jan 12 '12 at 17:08
@Ronny -- 14pt type will certainly need a larger baseline than 11pt. i have some ideas for making that part of the definition more flexible, and will report what i find. –  barbara beeton Jan 12 '12 at 17:27

use tabularx with a redefinition of the X columntype, then you do not need the calc package:

\documentclass[a4paper,div=calc]{scrartcl}
\usepackage[utf8]{inputenc}
\usepackage{booktabs,tabularx}
\renewcommand\tabularxcolumn[1]{m{#1}}
\begin{document}

\begin{tabularx}{0.5\linewidth}{>{\raggedleft}m{2.5em} X m{5.5em}}%
\toprule\textbf{\#}&\textbf{Name}&\textbf{Notes}\\\midrule%
A & Lorem ipsum dolor sit amet, consectetur adipisici elit&\\
B & An\newline even\newline higher\newline
row\newline with\newline linebreaks &         \\
2 & Short Entry &
\\\bottomrule
\end{tabularx}

\end{document}


-
but the text still looks like separate entries or items, not like text. the baselines are too far apart and too even, so it's not so easy to distinguish where A ends and B begins. and the uneven horizontal spacing in A makes it hard to read; ragged right is your friend here. –  barbara beeton Jan 11 '12 at 14:49
I know, but that was not the problem of the original question ... –  Herbert Jan 11 '12 at 14:56
Herbert your solution also works fine, though there are two drawbacks (and yes they are not mentioned in the first entry). First is, that the second column will be a parameter that i want to encapsulate either way (for example because i don't want to replace all \ by  \newlines before i insert that). Secondly - in my original code the table gets quite long, so i use longtable; getting longtable and tabularxto work together is - in my oppinion - quite a challenge. –  Ronny Jan 12 '12 at 7:34
Then use a minipage, where is the problem? And with package ltablex the tabularx environment can have a pagebreak –  Herbert Jan 12 '12 at 7:50
With ltablex it is a longtable with all that possibilities of head and foot definitions –  Herbert Jan 12 '12 at 8:38

The one solution mentioned by egreg in the comments to the original question was, to encapsulate the content and calculate the height to be used to a minipage. I adapted that to my MWE and that would look like this

\documentclass[a4paper,div=calc]{scrartcl}
\usepackage[utf8]{inputenc}
\usepackage{array,booktabs,calc}

\newcommand{\finalcell}[1]{%
\begingroup\sbox0{\begin{minipage}{.5\textwidth-6\tabcolsep-8em}%
\raggedright#1\end{minipage}}%
\xdef\finalheight{\the\dimexpr\ht0+\dp0+\smallskipamount\relax}%
\endgroup
\vspace{.5\cmidrulesep}
\begin{minipage}[t][\finalheight][t]{.5\textwidth-6\tabcolsep-8em}\raggedright#1\end{minipage}%&
}

\begin{document}
\begin{tabular}{>{\raggedleft}m{2.5em}m{.5\textwidth-6\tabcolsep-8em}m{5.5em}}%
\toprule\textbf{\#}&\textbf{Name}&\textbf{Notes}\\\midrule%

I additionally added \addlinespaces to the end of the lines, which could be optimized - i think - by increasing the linespace of the booktabs tabular in general before starting the tabular.
Yes, it might actually be a bug in the arraypackage, concerning line breaks in m-columns. –  Ronny Jan 20 '12 at 7:35