Summation rendering issue

[deedeekaka]

While trying to create this equation..

I noticed no matter my syntax, I could not get the summation to render properly..

This is my formula in Asciimath: EF_(N2O) = (sum_1^n (C_(N2O) ** 1.826 xx 10^(-6) ** Q) /P) /n

Every time I try to add parentheses to the numerator and denominators to section them off, the characters "n" and "1" are shifted to the side rather than remaining on the top and bottom of the Sigma character.

I am not sure if this is a syntax issue on my part or if it is perhaps a bug!

[drlippman]

Is this using AsciiMathML.js, or the AsciiMath input in MathJax, or AsciiMath converted to TeX rendered with a tex renderer?

[drlippman]

If it's using ASCIIMathML.js, please check your file, in the config near the top, and see if displaystyle is set = true. Having it =false would cause what you're seeing.

[deedeekaka]

This is using ASCIIMathML.js.. I've checked the config file and displaystyle is set to true.

[dpvc]

The AsciiMath rendering is actually correct. When a fraction is rendered in display style, the numerator and denominator are set in text style (this is part of the MathML specification for fractions -- see the second paragraph of section 3.1.6), which means that the summation will use limits in super- and subscript positions rather than under and over the summation sign. That is as expected, and is correct typography, in general.

Even though AsciiMath produces

<munderover>
  <mo>&#x2211;</mo>
  <mn>1</mn>
  <mi>n</mi>
</munderover>

for the summation, the operator dictionary entry for ∑ says that an <mo> containing this symbol will have movablelimts set to true, so when it is set in text mode (i.e., displaystyle is false, as it is in fractions), the <munderover> will be typeset as <msubsup> -- see the movablelimits entry in the table of mo attributes.

So the rendering is perfectly correct, and this is not a bug.

I don't think AsciiMath provides a means of setting the movablelimits attribute to false (or forcing displaystyle to true in the numerator), and I would definitely not recommend changing AsciiMath to always force displaystyle rendering for the sum.

One alternative, in this case, is to write

EF_(N2O) = 1/n sum_1^n (C_(N2O) ** 1.826 xx 10^(-6) ** Q) /P

instead, which is easier to read, in this case, anyway.