0
$\begingroup$

Here is e^{-\lvert\frac{x-\mu}{\sigma}\rvert}: $e^{-\lvert\frac{x-\mu}{\sigma}\rvert}$

The bars on the absolute value are too small, so I decided to make them bigger. Using \left and \right made them look pretty good:

e^{-\left\lvert\frac{x-\mu}{\sigma}\right\rvert}: $e^{-\left\lvert\frac{x-\mu}{\sigma}\right\rvert}$

But I thought I'd see what happened if I used \bigl and \bigr, which are supposed to increase the size of the delimiters by one quantum. And I found that the bars became much too big and fat:

e^{-\bigl\lvert\frac{x-\mu}{\sigma}\bigr\rvert}: $e^{-\bigl\lvert\frac{x-\mu}{\sigma}\bigr\rvert}$

I thought that \bigl and \bigr produced the smallest possible bigger-than-normal delimiters, and so \left and \right delimiters would necessarily be at least as big.

Is the bug in my understanding of \bigl and \bigr, or in their implementation?

I am using:

Google Chrome 23.0.1271.64 (Official Build 165188)
OS Mac OS X
WebKit 537.11 (@132838)
JavaScript V8 3.13.7.5

Here's a screenshot:

screenshot

Addendum

  1. With a different computer, the \bigl/\bigr bars don't look absurdly thick, although they are still taller than the \left/\right bars:

    Google Chrome 18.0.1025.142 (Official Build 129054)
    OS Linux
    WebKit 535.19 (@111933)
    JavaScript V8 3.8.9.16

$\endgroup$
5
$\begingroup$

There are actually two factors involved here. Mythealias has already discussed the TeX language issue of the way that \left...\right work in comparison to \bigl and \bigr, which explains the difference in height. MJD also complains about the thickness of the characters, which is actually a MathJax rendering issue, not a TeX one.

It turns out that the characters used for the vertical bar for \left...\right are taken from the script-sized font, while the ones for \bigl and \bigr are taken from the normal sized font. That means that the latter are heavier looking as they are slightly thicker. Also, the vertical bars are formed by using multiple smaller vertical bars, and they are overlapped in order to get the right total height. In this case, the original characters are nearly tall enough by themselves, but not quite, so two fairly large character are overlapping. That causes the anti-aliasing to appear extra heavy in the overlap area. So there are two reasons for the excessive thickness of the \big versions in this case.

I don't recall the reason why the script size wasn't used in this case, and I suspect it is not necessary. I will open an issue tracker for it so that it is taken care of in the next release of MathJax.

$\endgroup$
  • $\begingroup$ Thanks; this is exactly the response I was hoping to get. $\endgroup$ – MJD Nov 12 '12 at 22:04
  • $\begingroup$ What's the best place to report MathJax formatting and layout problems? se.math seems like a strange place to do it, but it does provide a lot of useful infrastructure for attaching screenshots and the like. What is most convenient for you? $\endgroup$ – MJD Nov 15 '12 at 15:21
  • $\begingroup$ Meta for se.math is fine (I check that regularly), but perhaps the best place is the MathJax User's Forum which is a Google group. Not quite as flexible an infrastructure, but it is where the MathJax users are linked in. $\endgroup$ – Davide Cervone Nov 16 '12 at 17:09
9
$\begingroup$

I don't think it is a bug. \left and \right constructs account for the size of content between them, whereas \bigl and \bigr are of predefined size. The l and r are to account for horizontal spacing. See here.

I think this question is better suited for tex.SE.

This is the output from latex with and without exponentiation (which uses scriptsize to change font size).

enter image description here

$\endgroup$

You must log in to answer this question.

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