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:
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:
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$.
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).
$\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$|
,\mid
,\vert
etc see here. $\endgroup$\not\vert
in Chrome 20.0.1132.47 beta on my Mac is essentially identical to the screenshot posted. $\endgroup$