Discuss bugs in itex2MML.

(Repost from the other discussion as this looks bug-like to me.)

Okay, let’s try this here. Compare and contrast:

How it ought to look:

With a \displaystyle at the start. In LaTeX, this is to ensure that the subscript to \lim is underset.

Now with a bit of grouping to help.

Somehow, the <mstyle displaystyle="true"> is getting inside the \lim processing, turning the <munder> in to a <msub>.

It’s a matter of the precedence rules that you expect not being respected by itex2MML

 \lim_{n\to 0}

is set with an <munder>. But, when you type

\displaystyle \lim_{n\to 0}

the precedence of the ”_” is not treated as being higher. The above is treated as equivalent to

{ \displaystyle \lim }_{n\to 0}

which is set with an <msub>. Putting in the grouping explicitly:

\displaystyle { \lim_{n\to 0} }

gives you what you were expecting.

I think this is confusing. Probably, you were expecting \displaystyle to behave more like \color{red} does (compare the definitions of COLOR and of DISPLAY, respectively, in itex2MML.y).

Update:

Let’s see: ${\displaystyle \underset{n\to 0}{\lim }\frac{1}{n}=0}$

Yup. itex2MML 1.4.8 works as you’d expect.

Once again: thank you very much!

The optional argument syntax for extensible arrows doesn’t swallow spaces correctly. If I type \xrightarrow [a]{b} then in LaTeX, this is equivalent to \xrightarrow[a]{b} because spaces are automatically swallowed after commands. However, in iTeX then they are not equivalent:

Thanks.

This looks like a bug in how Firefox renders MathML, but I thought I’d check with you first. How do $\hat{\otimes }$ and ${\displaystyle \hat{\otimes }}$ look to you? To me, the first has the hat offset to the right. I presume that it shouldn’t be so.

Correct.

The accents work correctly when accenting an <mi> (see this old bug), but not when accenting an <mo>, unless the style is displaystyle.

Thus:

You should file a bug report.

Done

(My word, but that’s a complicated form. “What did you do?” I looked at a MathML web page. “What happened?” It didn’t look right. “What should have happened?” It should have looked right.)

‘Cept it’s not a Firefox bug; it’s a Gecko Core (MathML Component) bug. As filed, no one relevant will see it. If you, as the Reporter of the bug, can reclassify it, maybe it will have a fighting chance of getting some attention.

Seems that I can so I have.

According to Frédéric, it’s a feature, not a bug. I could change \widehat{} (and its cousins) to wrap their output in an <mstyle displaystyle='true'>, but that might have unintended side-effects.

I notice that Frederic has now closed this and says that the correct way to handle them is with movablelimits="false". So that makes this now an itex bug again!

Identifiers lumped together in MathML output

Example: $X_ab$ produces output $X_{\mathrm{ab}}$ <msub><mi>X</mi> <mi>ab</mi></msub>

Output should be more or less $X_{a}b$ <math><msub><mi>X</mi> <mi>a</mi></msub><mi>b</mi></math>

Two things wrong with this: first the “b” would never be subscripted in LaTex, and second, two variables should not be lumped in the same <mi></mi> element because this causes MathML to set them in upright rather than italic type. So each variable really needs to be in its own <mi></mi>

That’s a “feature”, not a bug.

As described here, $ab$ is a single token in itex (tranlated to <mi>ab</mi>); $a b$ are two tokens (translated to <mi>a</mi><mi>b</mi>). MathML is semantically-richer than (La)TeX, and this convention gives you the ability to enter multi-character tokens, which will be interpreted as such, when translated to MathML.

Good enough then and thank you. I thought $X_a b$ was producing an unacceptable space, but that was just a Firefox peculiarity.