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: https://tex.stackexchange.com/a/11694/13450

\diaghead{\theadfont Diag ColumnmnHead II}%
{Diag\\Column Head I}{Diag Column\\Head II}&
& foo & bar \\

Which yields this:

result from MWE

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:

the line end point does not seem to lie in the line crossing

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

TikZ screenshot with two end sticking out

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, 2013 at 10:52
  • 2
    It is supposed that diagbox does not have this issue.
    – Leo Liu
    Jul 3, 2014 at 2:53

3 Answers 3


The tikz solution given in Diagonal lines in table cell 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:

  $\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};

&&&&20\\ \hline
&&&&30\\ \hline
&&&&45\\ \hline
15&12&18&50&\diag{.1em}{.5cm}{$a_i$}{$b_j$}\\ \hline



  • 6
    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 Jan 8, 2013 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, 2013 at 17:22
  • 1
    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. Feb 10, 2013 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, 2013 at 23:08
  • Just wanted to point to this follow-up question: tex.stackexchange.com/questions/110340/…
    – Christian
    Apr 23, 2013 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.

  • 1
    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, 2013 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, 2013 at 10:47
  • 2
    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, 2013 at 10:51

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.



\diagbox{Diag\\ Column Head I}{Diag Column\\Head II}&
& foo & bar \\


You need several compilations because of the PGF/Tikz nodes.

Output of the above code

With a zoom:

Zoom on the intersections of the rules

  • The current version of standalone package has some error when used with the latest LaTeX kernel, better to stick with standalone (or use preview package).
    – user202729
    Mar 5 at 23:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .