Open drlippman opened 9 years ago
Here's what's happening: currently, (-3,6)
produces
<math xmlns="http://www.w3.org/1998/Math/MathML">
<mstyle displaystyle="true">
<mrow>
<mo>(</mo>
<mo>-</mo>
<mn>3</mn>
<mo>,</mo>
<mn>6</mn>
<mo>)</mo>
</mrow>
</mstyle>
</math>
This means that the minus sign is an infix operator, so gets the space of a binary minus sign, not a unary negation. The recommended way to code -3
is <mrow><mo>-</mo><mn>3</mn></mrow>
. The extra <mrow>
will cause the minus to be a prefix operator, and get the appropriate spacing.
An alternative would be to use <mo form="prefix">-</mo><mn>3</mn>
, but the <mrow>
approach is what the spec recommends.
Another reason that the TeX output differs from the AsciiMath is that AsciiMath uses MathML spacing, but TeX uses TeX spacing (the HTML-CSS and SVG output renders use TeX spacing rather than MathML spacing unless told otherwise, but we turned on MathML spacing for AsciiMath, since it assumed those rules in some instances, namely things like {x|x>1}
).
I noticed that the TeX processor produces for $(-3,6)$
<math xmlns="http://www.w3.org/1998/Math/MathML">
<mo stretchy="false">(</mo>
<mo>−<!-- − --></mo>
<mn>3</mn>
<mo>,</mo>
<mn>6</mn>
<mo stretchy="false">)</mo>
</math>
I'm guessing the use of ࢤ
is also contributing to the layout difference? I was figuring that I was going to need to adjust the AM processor to return that symbol for negation - is that correct?
No, the HTML-CSS and SVG output converts the dash to U+2212 automatically (when it is the single character within an <mo>
). For native MathML, it will depend on the browser's implementation. Firefox does seem to convert it as well. I doubt WebKit does.
Ahh, ok. So the correct fix is to wrap the negation and what it's applying to in a separate
So digging into this again, it appears the only way to address this issue would be to separate the CONST token type into two subtokens: ones that "separate" expressions (like , ; : = < ->
and a bunch others) and ones that don't (like numbers, variables, basic operators).
A negative following a separating CONST or a LEFTBRACKET would be treated like a negation, while a negative following a standard CONST would act as a minus operator.
Do you see any pitfalls of this approach?
Found an issue already. The negative in 4,-2/3
would display differently than in -2/3,4
which isn't sensible.
Could you resolve this problem by looking for separating CONST, LEFTBRACKET, or no previous token?
I think there are other situations you might need to worry about, like summations and integrals. I would hope that int -2x dx
would use negation, though I suppose you could do int {:-2x:} dx
if you needed to.
Could you resolve this problem by looking for separating CONST, LEFTBRACKET, or no previous token?
I think there are other situations you might need to worry about, like summations and integrals. I would hope that
int -2x dx
would use negation, though I suppose you could doint {:-2x:} dx
if you needed to.
The solution is very much appreciated.
The spacing between the negative sign and the number is incorrect when the negative is preceeded by a parenthesis. For example in
(-3,6)
, the negative is spaced like subtraction, like in5-3
, rather than the tighter spacing in-3
From a quick glance, it looks like the TeX renderer uses− rather than - for the negative sign; I'm presuming this is what's causing the different spacing.
We might want to see if we can find a way to distinguish in the AM parser between subtraction and a negative symbol so we can mimic the spacing of the TeX renderer.