Forums itex2MML

Bugs

Subscribe to Bugs 16 posts, 3 voices

 
admin Administator 57 posts

Discuss bugs in itex2MML.

 
Andrew Stacey 118 posts

(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:

lim n01n=0\lim_{n\to 0} \frac{1}{n} = 0

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

lim n01n=0\displaystyle \lim_{n\to 0} \frac{1}{n} = 0

Now with a bit of grouping to help.

lim n01n=0\displaystyle { \lim_{n\to 0} \frac{1}{n} = 0 }

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

 
admin Administator 57 posts

edited 2 years ago

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: lim n01n=0

lim n01n=0\textstyle \lim_{n\to 0} \frac{1}{n} = 0

Yup. itex2MML 1.4.8 works as you’d expect.

 
Andrew Stacey 118 posts

Once again: thank you very much!

 
Andrew Stacey 118 posts

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:

[a]bab\xrightarrow [a]{b} \xrightarrow[a]{b}
 
admin Administator 57 posts

Thanks.

 
Andrew Stacey 118 posts

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

 
admin Administator 57 posts

edited 2 years ago

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:

MathMLDisplay
<math display='inline' xmlns='http://www.w3.org/1998/Math/MathML'><mover><mo>⊗</mo><mo>^</mo></mover></math>^
<math display='inline' xmlns='http://www.w3.org/1998/Math/MathML'><mstyle displaystyle='true'><mover><mo>⊗</mo><mo>^</mo></mover></mstyle></math>^
<math display='block' xmlns='http://www.w3.org/1998/Math/MathML'><mover><mo>⊗</mo><mo>^</mo></mover></math>^
<math display='inline' xmlns='http://www.w3.org/1998/Math/MathML'><mstyle textstyle='true'><mover><mo>⊗</mo><mo>^</mo></mover></mstyle></math>^

You should file a bug report.

 
Andrew Stacey 118 posts

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.)

 
admin Administator 57 posts

edited 2 years ago

‘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.

 
Andrew Stacey 118 posts

Seems that I can so I have.

 
admin Administator 57 posts

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.

 
Andrew Stacey 118 posts

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!

 
jl344 4 posts

Identifiers lumped together in MathML output

Example: $X_ab$ produces output X ab <msub><mi>X</mi> <mi>ab</mi></msub>

Output should be more or less X ab <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>

 
admin Administator 57 posts

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.

 
jl344 4 posts

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

Forums itex2MML