# How to diagonally divide a table cell … properly?

There have been many threads discussing solutions 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: http://tex.stackexchange.com/a/11694/13450

\documentclass{standalone}
\usepackage{makecell}
\begin{document}
\begin{tabular}{|l|c|c|}\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 http://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)?

-
The issue with the TikZ solution is I suspect different to the one with 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 Wright Jan 8 '13 at 10:52
It is supposed that diagbox does not have this issue. –  Leo Liu Jul 3 '14 at 2:53

The tikz solution given in http://tex.stackexchange.com/a/17748/12571 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:

-
Alternatively, set the line width on the node to 0pt with line width=0pt. Good diagnosis! For further information on why this occurs, see tex.stackexchange.com/q/29874/86 –  Loop Space Jan 8 '13 at 12:25
Great, thanks. I had to add yet another parameter to allow arbitrary heights as well as width and it's really a shame that you can't just determine these automatically but all in all in a great solution :) –  Christian Jan 8 '13 at 17:22
Hm. This looks nice but I need to know the dimensions of the cell. I like using "tabu" for tables so that I don't need to care about width of columns. It'd be cool if there was a generic solution. –  Frederick Nord Feb 10 '13 at 23:02
@FrederickNord I agree, there really should be a package that provides a simple \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 Mar 12 '13 at 23:08
Just wanted to point to this follow-up question: tex.stackexchange.com/questions/110340/… –  Christian Apr 23 '13 at 19:15

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 (see in particular Leo Liu's answer, which uses TikZ only as far as dealing with the split cell). The diagbox package is also available: it uses pict2e to implement the split box.

-
So 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 Jan 8 '13 at 10:00
@Christian Loading 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 Jan 8 '13 at 10:47
Ok so I gather despite all the threads and many solutions to this problem, a real solution without going all-TikZ is still outstanding. I should probably open yet another question for this. Thanks for the great explanation so far! –  Christian Jan 8 '13 at 10:51