I think that this is directly related to this other question on Firefox rendering.

I have recently upgraded to Firefox 13.0.1 (on Windows) and \not \vert is not rendering correctly, for example in this answer.

A screen shot of that answer: enter image description here

  • 1
    $\begingroup$ BTW $\nmid$ is better for this than $\not\vert$. Compare: $a\nmid b$ and $a\not\vert b$. (The first one is with \nmid.) Even $\not\mid$ looks fine for me: $a\not\mid b$. $\endgroup$ Commented Jun 30, 2012 at 14:41
  • $\begingroup$ @Martin, \not\vert doesn't render properly whether it's better or worse. $\endgroup$ Commented Jun 30, 2012 at 14:42
  • $\begingroup$ @Henning, in that case could you roll your comments into an answer? It seems that \not\vert is best avoided and probably explains why different browsers' attempts to render it produce different results. $\endgroup$ Commented Jun 30, 2012 at 17:22
  • 3
    $\begingroup$ $\TeX$ tip: for proper usage of |, \mid, \vert etc see here. $\endgroup$ Commented Jun 30, 2012 at 18:03
  • $\begingroup$ The rendering of \not\vert in Chrome 20.0.1132.47 beta on my Mac is essentially identical to the screenshot posted. $\endgroup$
    – Isaac
    Commented Jun 30, 2012 at 20:16
  • $\begingroup$ @Isaac, It looks even worse on Internet Explorer. Methinks I should have checked a little before posting. $\endgroup$ Commented Jun 30, 2012 at 20:20

2 Answers 2


The treatment of \not is one of the places where MathJax differs somewhat from $\rm\TeX$ itself. That is because MathJax represents the mathematics internally using Presentation MathML, and there is no natural construct corresponding to \not in MathML.

The $\rm\TeX$ version of \not generates a zero-width character that overlaps the character to its right, and is given the spacing of a relation. Because two adjacent relations get no extra space between them, this causes the slash to overlap the following relation making the compound character that is the negated version of the following relation. The size of the slash is designed to match up with the size of most relations (like less-than or subset) so that the slash is properly centered on the following symbol.

That only works well if the following symbol is the same width as the less-than sign or the subset symbol. Something like "|" is too thin for that, and so it doesn't work well. Note that a \not\vert b in $\rm\TeX$ has the spacing of a relation between the a and the slash, the spacing of a relation between the slash and the vertical bar, and no extra spacing between the vertical bar and the following b (since they are both ordinals). The result is $$a\not|b$$ (the spacing is complicated a bit further by the fact that the glyphs for both the slash and the vertical bar have extra space on both sides of the visible part of the character, so the space between the a and the / is larger than between the / and |, though the extra space inserted by $\rm\TeX$ is the same in both cases).

On the other hand, a \not\mid b would produce $$a\not\mathrel{\vert} b$$ since \mid is a relation and so there is no extra space between the slash and vertical bar, and the spacing before the slash and after the bar is the same. Neither of these is what you would want, and so Henning is correct that \nmid is part of the AMSsymbols package in order to overcome the bad spacing of these two examples. (Knuth also was concerned about such issues, and so there is \ne rather than \not= because the spacing is just a bit off with \not=).

Now MathJax uses MathML as its internal format, and so has to represent these negations in that form. Where $\rm\TeX$ uses several relations in a row (e.g., / followed by = for example), MathML puts both characters into a single <mo> (math operator) element. The characters inside the <mo> are in Unicode, and Unicode also has a method of producing combined characters; but Unicode uses zero-width characters that lap to the left and follow the character they modify, the opposite of how $\rm\TeX$ works.

That means that MathJax has to reverse the order of the characters so that \not\vert would become U+2223 U+0338 (divides followed by combining long solidus overlay). This is why a \not\vert b produces $a\not\vert b$ (the spacing is that of an ordinal, so no extra space between the a and |, and then the overlay slash extends to the left, with no extra space before the b. This is different from how $\rm\TeX$ handles it.

In addition, Unicode has pre-combined versions of a number of symbols. For example, U+2286 is $\subseteq$ while U+2288 is $\not\subseteq$. So MathJax combines \not with the following character, when that is possible. That is why a \not\mid b produces $a\not\mid b$ in MathJax even though in $\rm\TeX$ this would be badly spaced. This is one of the few cases where MathJax chooses better semantic meaning of the underlying MathML over fidelity to $\rm\TeX$ output.

Finally, in the case where \not is followed by something other than a single character, MathML doesn't have a natural way to produce that, so MathJax tries to duplicate the $\rm\TeX$ rightward overlay instead. E.g., a \not\mathrel{XX} b produces $a\not\mathrel{XX}b$ rather than $a\mathrel{X\not X}b$. This does allow you to get the $\rm\TeX$ result as in a\not{\vert}b producing $a\not{\vert}b$.

Anyway, that's the story of \not in MathJax, which is a bit different from the story in $\rm\TeX$.

  • $\begingroup$ +1 Thanks for the very informative answer. It is much appreciated. $\endgroup$ Commented Jul 1, 2012 at 23:33
  • $\begingroup$ +1 as well, thanks very much. $\endgroup$ Commented Jul 1, 2012 at 23:45

According to my experiments, actual (La)TeX also gets \not\vert wrong: It does produce two crossing lines, but with quite strange spacing surrounding them.

Per this tex.SE question, \vert is not intended to produce a symbol with relation spacing at all, so arguably an author has no right to expect \not\vert to do anything meaningful in the first place.

The existence of \nmid probably relates to the fact that \not\mid gets it completely wrong even in actual (La)TeX.

(The linked tex.SE answer claims that there is a \divides, but neither MathJaX nor LaTeX-out-of-the-box recognizes that at all, and I'm not sure which package it is from -- neither amsmath nor amssymb do the trick).

  • $\begingroup$ As an entirely off-topic remark (since rendering of slashes in LaTeX is brought up): there is a reason why someone wrote the slashed package. $\endgroup$ Commented Jul 2, 2012 at 9:20

You must log in to answer this question.

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