Add an AMScd extension #420

Closed
fred-wang opened this Issue Mar 22, 2013 · 19 comments

2 participants

@fred-wang

Just opening an issue for this, as we don't seem to have one yet.

dpvc@master...AMScd

@dpvc
MathJax member

I think this is ready to go, so I'm marking it "Ready for Review".

@fred-wang

It looks like the packed autoload-all.js file is causing conflicts with the current master/develop branches.

@fred-wang

I prepared some tests

LaTeXToMathML/AMScd/amscd-1.html
LaTeXToMathML/AMScd/amscd-2.html
LaTeXToMathML/AMScd/amscd-3.html
LaTeXToMathML/AMScd/arrows-1.html
LaTeXToMathML/AMScd/arrows-2.html
LaTeXToMathML/AMScd/min-1.html
LaTeXToMathML/AMScd/min-2.html

I didn't add references yet, because it seems that I get different output with the ShowSource or with the native MathML source. I'm not sure if that's a bug or not.

One issue I noticed is that one can't do something like @<a<< because it will be badly parsed by the HTML parser. Hence people have to write @<{a}<<. I guess we can't fix that, but that's something we should remember to document.

Another thing is about the horizontal stretchy "=", that I think we also use for the chemistry extension. The MathML operator dictionary does not specify the equal sign as stretchy and fonts like e.g. STIX do not seem to have horizontal construction for it. Gecko does not support this and I don't know about MathPlayer. I don't remember when we chose to use the horizontal equal sign but we should probably coordinate with other projects and the Math WG. Perhaps Unicode has a "double horizontal bar" for that purpose that should be included in the math operator dictionary with stretchy=true by default.

@dpvc
MathJax member

It looks like the packed autoload-all.js file is causing conflicts with the current master/develop branches.

Well, the AMScd branch is very old (pre v2.1) so that is not a surprise. There are two ways we could handle that. First, I could just make a new AMScd branch from develop so that it will merge cleanly now (without the packed versions). Or, we could do the merge, get the conflict, and then perform

git add extensions/TeX/autoload-all.js
git checkout extensions/TeX/autoload-all.js

to resolve the conflict, but get back the original version of the packed autoload-all.js file. Then commit the result.

Either is fine. Since there is really no history in the AMScd branch, we don't really lose anything with a new branch (other than the fact that the work was done earlier). What do you think?

@fred-wang

I'm fine if you create a new branch (e.g. issue420) with only the changes to the two unpacked files. The packed files with basically a single line with all the code are more likely to get merge conflicts, so I'm happy if we can avoid them during the development.

@dpvc
MathJax member

One issue I noticed is that one can't do something like @<a<< because it will be badly parsed by the HTML parser. Hence people have to write @<{a}<<

There are two other possible approaches. ONe is to use CDATA, as in

\[<!--[CDATA[
\begin{CD} 
A @>a>b> B\\ 
@VlVrV @AlArA\\ 
C @<a<b<D 
\end{CD}
]]-->\]

or to use spaces, as in

\[\begin{CD} 
A @>a>b> B\\ 
@VlVrV @AlArA\\ 
C @< a < b < D 
\end{CD}\]

(or put the code in one of MathJax's <script type="math/tex;mode=display">, or use &lt;, etc.). If people are using content-management systems, they may handle the conversion to &lt;` for them.

@dpvc
MathJax member

Another thing is about the horizontal stretchy "=" ...

I don't see another alternative in the Unicode characters for this. Of course, stretching the equal sign is easy, since you just have to repeat it (it is its own extender character). I don't know if MathPayer supports it either. I'd be happy if you wanted to coordinate with other projects on supporting the stretchy equals.

@dpvc
MathJax member

The packed files ... are more likely to get merge conflicts, so I'm happy if we can avoid them during the development.

I've stopped creating them, as per your previous request. This commit was created long before that, however, which is why they are there. I'll make the new branch.

@dpvc dpvc pushed a commit to dpvc/MathJax that referenced this issue Mar 23, 2013
Davide P. Cervone Add AMS CD environment. Resolves issue #420. d724248
@dpvc dpvc pushed a commit to dpvc/MathJax that referenced this issue Mar 23, 2013
Davide P. Cervone Fix version number in autoload-all. Issue #420 98755b9
@dpvc
MathJax member

OK, I made the new issue420 branch.

@fred-wang

Thanks. I'll write a mail to the Math WG. BTW, I see for example that LaTeXML implements AMScd the same way (using tables and stretchy equal signs):

http://www.maths-informatique-jeux.com/maths/memoire_groupes_quantiques/Ch1.S5.html

@dpvc
MathJax member

I see for example that LaTeXML implements AMScd the same way

I really don't see any other way to do it, but thanks for the further information.

Should I merge the branch into develop at this point?

@fred-wang

Should I merge the branch into develop at this point?

There's one thing I didn't have time to check:

I get different output with the ShowSource or with the native MathML source. I'm not sure if that's a bug or not.

Essentially, the attributes that are only added in the CD_env

arraydef: {
columnalign: "center",
columnspacing: CONFIG.colspace,
rowspacing: CONFIG.rowspace,
displaystyle: true

@fred-wang

(Sorry, I unintentionally pressed enter). I wanted to say that columnalign and displaystyle do not show up in the ShowMath menu but they are in the MathML DOM.

@dpvc
MathJax member

columnalign and displaystyle do not show up in the ShowMath menu but they are in the MathML DOM

For math that came from MathML originally, ShowMath will show exactly the attributes that were given, but for math that came from TeX or AsciiMath, MathJax doesn't have a distinction between attributes that are using their default values and those that are set explicitly, so ShowMath only displays the attributes that differ from their default values. In this case, the default for columnalign is centered, so it doesn't show that. But the default for displaystyle should have been false (I think) so it should have shown that. I'll have to check into that one.

@fred-wang

OK, I think that's because I looked at a display equation. For the inline equations the displaystyle="true" is added.

@dpvc
MathJax member

OK, that sounds like that's probably it. Do you want me to look into it further?

@fred-wang

No, I think that's ok. You can merge it. I'll just write the test references later.

@dpvc dpvc pushed a commit to dpvc/MathJax that referenced this issue Mar 23, 2013
Davide P. Cervone Merge branch 'issue420' into develop
Resolves issue #420.
8b5de06
@dpvc
MathJax member

OK, merged.

@fred-wang

=> In testsuite

@dpvc dpvc closed this May 17, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment