How to diagonally divide a table cell … properly?There have been
many threads discussing solutions
[1] to the task of drawing a diagonal line in a table cell. There are also two packages to do this, slashbox and the better looking makecell with its \diaghead command. Apparently, better looking doesn't mean good looking though.
I just stole a MWE from one of the threads: https://tex.stackexchange.com/a/11694/13450
\documentclass{standalone}
\usepackage{makecell}
\begin{document}
\begin{tabular}{|l|c|c|}\hline
\diaghead{\theadfont Diag ColumnmnHead II}%
{Diag\\Column Head I}{Diag Column\\Head II}&
\thead{Second\\column}&\thead{Third\\column}\\
\hline
& foo & bar \\
\hline
\end{tabular}
\end{document}
Which yields this:
Looks more or less fine at first glance at this low resolution (which is not always the case BTW) but with a better resolution, the lower right corner looks somewhat awkward:
These things even show in print and it doesn't look like being off by just one pixel so it's probably not just a rendering problem.
Does anyone know why this happens and how to prevent it? (Preferably without drawing the whole table as a TikZ picture as has been suggested.)
Edit in response to Joseph's answer:
This TikZ solution by Leo Liu also has similar issues https://tex.stackexchange.com/a/17748
It appears to be rather manual, too, so maybe it's just a calibration issue. But is it really necessary to go down to the 6400% level in Adobe Reader to fine-tune parameters every time you change the content of the "diagonal cell" (for lack of a better word)?
ACCEPTED]
The tikz solution given in Diagonal lines in table cell [1] by Leo Liu can be fixed by taking into account the width of the node borders (even if those borders are not drawn).
The following MWE gives the right result:
\documentclass[11pt]{article}
\usepackage[T1]{fontenc}
\usepackage{array}
\usepackage{makecell}
\newcolumntype{x}[1]{>{\centering\arraybackslash}p{#1}}
\usepackage{tikz}
\newcommand\diag[4]{%
\multicolumn{1}{p{#2}|}{\hskip-\tabcolsep
$\vcenter{\begin{tikzpicture}[baseline=0,anchor=south west,inner sep=#1]
\path[use as bounding box] (0,0) rectangle (#2+2\tabcolsep,\baselineskip);
\node[minimum width={#2+2\tabcolsep-\pgflinewidth},
minimum height=\baselineskip+\extrarowheight-\pgflinewidth] (box) {};
\draw[line cap=round] (box.north west) -- (box.south east);
\node[anchor=south west] at (box.south west) {#3};
\node[anchor=north east] at (box.north east) {#4};
\end{tikzpicture}}$\hskip-\tabcolsep}}
\begin{document}
\setlength{\extrarowheight}{0.1cm}
\begin{tabular}{|x{0.5cm}|x{0.5cm}|x{0.5cm}|x{0.5cm}|x{0.5cm}|}\hline
&&&&20\\ \hline
&&&&30\\ \hline
&&&&45\\ \hline
15&12&18&50&\diag{.1em}{.5cm}{$a_i$}{$b_j$}\\ \hline
\end{tabular}
\end{document}
Detail:
0pt with line width=0pt. Good diagnosis! For further information on why this occurs, see tex.stackexchange.com/q/29874/86 - Andrew Stacey
\diagcell{}{} macro that you can use in any table cell and that's it. But maybe this is another case for tex.stackexchange.com/questions/27440/what-cant-tex-do - Christian
Overfull hbox warning. A possible fix I come up with is gist.github.com/user202729/cbd890483154fb46f99f1e81bd9c5837 (although I don't know if it has some other consequences) - user202729
The makecell package uses LaTeX's picture environment for drawing. Rather than use specials, this uses pre-draw graphical elements stored in appropriate fonts. However, such an approach has available only a fixed range of slopes for lines (amongst other limitations). What appears to happen here is that makecell is using the closes height/width it can with this limitation, but that this means that the width may be out by an amount dependent on the different between the actual height/width ratio and the nearest available line slope.
In particular, \diaghead has an optional ratio argument which sets the height-to-width ratios, but this has to be in integer values (try \diaghead(5,-2.5)). Thus the code is not allow us to bypass the fixed ratios available even with more extended picture support (for example the eepic package).
Using TikZ circumvents this problem as the line is then draw as a special, which may be of any angle. (Limitations on specials are down to the driver, not the fonts available). It's also worth noting that TikZ is written assuming floating point values from the start, so correctly handles the calculations.
A number of approaches to the problem are available in
Diagonal lines in table cell
[1] (see in particular
Leo Liu's answer
[2], which uses TikZ only as far as dealing with the split cell). The
diagbox
[3] package is also available: it uses
pict2e
[4] to implement the split box.
pict2e fixes the problem you described and therefore diagbox doesn't suffer from it? The answer you highlighted also produces imperfect results BTW. I'm going to add this to my question. - Christian
pict2e does not fix diagbox as it still uses a fixed angle. I didn't check to the zoom leave you've used on the other solutions: there is the possibility that there is some rounding error somewhere or similar. David Carlislie suggested in chat that the best approach is probably to work out the sloping part then alter the column width to match this: I've not tested. - Joseph Wright
With {NiceTabular} of nicematrix and its built-in command \diagbox, you will have a perfect output because the diagonal rule is drawn by PGF/Tikz.
\documentclass{standalone}
\usepackage{nicematrix}
\begin{document}
\begin{NiceTabular}{|w{l}{4cm}|c|c|}\hline
\rule[-5mm]{15mm}{0cm}
\diagbox{Diag\\ Column Head I}{Diag Column\\Head II}&
\Block{}{Second\\column}&\Block{}{Third\\column}\\
\hline
& foo & bar \\
\hline
\end{NiceTabular}
\end{document}
You need several compilations because of the PGF/Tikz nodes.
With a zoom:
standalone package has some error when used with the latest LaTeX kernel, better to stick with standalone (or use preview package). - user202729
diagbox, as the backends are totally separate. In the TikZ case, I wonder about rounding errors: probably best to ask there (as a comment on the answer). - Joseph Wrightdiagboxdoes not have this issue. - Leo Liu