MathJax test results - 2013-04-30

[Frédéric WANG]

Chrome Linux:

http://mathjaxtest.s3.amazonaws.com/v2.1-candidate/2013-04-30/Linux_Chrome_default_STIX_HTML-CSS-5.html.gz
http://mathjaxtest.s3.amazonaws.com/v2.1-candidate/2013-04-30/Linux_Chrome_default_TeX_HTML-CSS.html.gz
http://mathjaxtest.s3.amazonaws.com/v2.1-candidate/2013-04-30/Linux_Chrome_default_TeX_SVG.html.gz

Firefox Linux:

http://mathjaxtest.s3.amazonaws.com/v2.1-candidate/2013-04-30/Linux_Firefox_default_STIX_HTML-CSS-1.html.gz
http://mathjaxtest.s3.amazonaws.com/v2.1-candidate/2013-04-30/Linux_Firefox_default_TeX_HTML-CSS.html.gz
http://mathjaxtest.s3.amazonaws.com/v2.1-candidate/2013-04-30/Linux_Firefox_default_TeX_SVG.html.gz

Opera Linux:

http://mathjaxtest.s3.amazonaws.com/v2.1-candidate/2013-04-30/Linux_Opera_default_TeX_HTML-CSS.html.gz
http://mathjaxtest.s3.amazonaws.com/v2.1-candidate/2013-04-30/Linux_Opera_default_TeX_SVG.html.gz

--
Fr�d�ric Wang
maths-informatique-jeux.com/blog/frederic

[Frédéric WANG]

Chrome Windows:

http://mathjaxtest.s3.amazonaws.com/v2.1-candidate/2013-04-30/Windows_Chrome_default_STIX_HTML-CSS.html.gz
http://mathjaxtest.s3.amazonaws.com/v2.1-candidate/2013-04-30/Windows_Chrome_default_TeX_HTML-CSS.html.gz
http://mathjaxtest.s3.amazonaws.com/v2.1-candidate/2013-04-30/Windows_Chrome_default_TeX_SVG.html.gz

Firefox Windows:

http://mathjaxtest.s3.amazonaws.com/v2.1-candidate/2013-04-30/Windows_Firefox_default_STIX_HTML-CSS.html.gz
http://mathjaxtest.s3.amazonaws.com/v2.1-candidate/2013-04-30/Windows_Firefox_default_TeX_HTML-CSS.html.gz
http://mathjaxtest.s3.amazonaws.com/v2.1-candidate/2013-04-30/Windows_Firefox_default_TeX_SVG.html.gz

Opera Windows:

http://mathjaxtest.s3.amazonaws.com/v2.1-candidate/2013-04-30/Windows_Opera_default_TeX_HTML-CSS.html.gz
http://mathjaxtest.s3.amazonaws.com/v2.1-candidate/2013-04-30/Windows_Opera_default_TeX_SVG.html.gz

[Frédéric WANG]

I didn't look too carefully, but one remark: I replaced the error
retrieving to rely on the MathJax signal rather than an exception in
some cases, but it seems that it does always not work very well.
Especially when the error is on purpose like with recursive macro,
formatError etc

On 30/04/2013 17:09, Davide P. Cervone wrote:
> Thanks, Fred. These don't look too bad. It looks like a bunch of them are probably the same errors, so I'm hopeful that a few fixes will take care of a lot of it. Most of the image failures are small pixel differences. So it looks like we are in pretty good shape for the first pass.
>
> Davide

[Davide P. Cervone]

I've gone through the Firefox TeX errors, and have the following comments and fixes. The other runs are very similar, and I will go through to see what the differences are, but this should take care of most of them.

Davide



LINUX FIREFOX TEX

--------------------------------------------

API/Hub/formatError-1.html

It appears that the

new Error("my error")

line may be getting trapped by the test framework? I can't reproduce the problem (the test and reference files seem to produce the expected output for me).

--------------------------------------------

API/Hub/mathProcessingError-1.html

The test passes by hand for me.

--------------------------------------------

API/Hub/messagehook-1.html

The failure is due to the presence of _moz-math-font-style="italic" in the source MathML. (This isn't removed by MathJax until the conversion from the original text to the internal format.) So I guess the reference value has to change until Firefox no longer applied these values. Alternatively, you can remove them in your xMathJaxConfig routine.

--------------------------------------------

API/OutputJax/variables-3.html

Because you are running the unpacked version, the fontDir and imageDir are different (they need to access the main directory, which is one level higher than the unpacked directory. Switching to the packed version should resolve the problem.

--------------------------------------------

AsciiMathToMathML/issue384.html

The NativeMML output automatically adds the outer <mrow> for Firefox, so there is no need to include it in the reference file. (It will be added when the Math is output for the reference.) So removing that row should resolve the problem.

--------------------------------------------

Configuration/Hub/errorSettings-1.html

Again, it looks like the test framework may be trapping the "new Error()" call. It may be necessary to use a hard-coded structure, like

{message: "my error"}

instead.

--------------------------------------------

Configuration/Hub/v1.0-compatible-1.html

Test should be removed (or disabled) since v1.0-warning.js is now removed.

--------------------------------------------

Configuration/Hub/positionToHash-2.html

I don't get the error when running the test by hand.

--------------------------------------------

Configuration/tex2jax/preview-1.html
Configuration/tex2jax/preview-2.html
Configuration/tex2jax/preview-3.html
Configuration/tex2jax/preview-4.html
OK, these were due to an error in the changes I made to skip over the previews. I've fixed that in the develop branch.

--------------------------------------------

Configuration/tex2jax/processRefs-1.html
Configuration/TeX/equationNumbers/autoNumber-1.html
Configuration/TeX/equationNumbers/autoNumber-2.html
Configuration/TeX/equationNumbers/formatNumber-1.html
Configuration/TeX/TagIndent-1.html
Configuration/TeX/TagSide-1.html
LaTeXToMathML/environments/multiline-2a.html
LaTeXToMathML/environments/multiline-2b.html
LaTeXToMathML/references/tag-1.html
LaTeXToMathML/references/tag-2.html
LaTeXToMathML/references/tag-3.html
LaTeXToMathML/references/notag-1.html
LaTeXToMathML/issue428.html
MathMLToDisplay/Presentation/TablesAndMatrices/mlabeledtr/mlabeledtr1.html
MathMLToDisplay/Presentation/TablesAndMatrices/mlabeledtr/mlabeledtrAside1.html
MathMLToDisplay/Presentation/TablesAndMatrices/mlabeledtr/rec-mlabeledtr.html
MathMLToDisplay/issue296.html
UI/zoom-box-2.html

Fixed in issue 428 (23edb).

--------------------------------------------

Configuration/TeX/MAXBUFFER-1.html
Configuration/TeX/MAXMACROS-1.html
LaTeXToMathML/macro/macro-4.html
LaTeXToMathML/references/label-1.html
LaTeXToMathML/issue236.html
LaTeXToMathML/limits-4.html
LaTeXToMathML/primes-3.html
Parsing/issue228.html

I am not able to reproduce the error (the tests work by hand). These all test the generation of error messages, and since it seems that "new Error()" is trapped by the test framework, that may be the cause of this. MathJax does use "new Error()" internally, so that could be the problem.

(The ref-test for LaTeXToMathML/issue236.html will need to be changed, as negative dimens are now accepted (but mostly ignored).)

--------------------------------------------

LaTeXToMathML/mhchem/amounts-1.html
LaTeXToMathML/style-2.html

This was due to the changes for \mathchoice, which incorrectly implemented Core(). I have fixed it in develop.

--------------------------------------------

MathMLToDisplay/ErrorHandling/NumChildren/noChildPresentation.html

Fixed in develop.

--------------------------------------------

MathMLToDisplay/General/GenAttribs/href-1.html
MathMLToDisplay/Presentation/CSS/mfrac/mfrac-03.html
MathMLToDisplay/Presentation/CSS/msubsup/msubsup-04.html
MathMLToDisplay/issue378.html

The difference in images is not apparent to the eye, or is a pixel-sized error.

--------------------------------------------

MathMLToDisplay/Presentation/CSS/mspace/mspace-02.html

Because the MathML spec says that the linebreak attribute is to be ignored if one of the dimensional attributes is present, the ref-test should be changed. All the linebreak="newline" misplaces should NOT have width="0" set explicitly.

--------------------------------------------

MathMLToDisplay/Presentation/ScriptsAndLimits/mmultiscripts/linebreak-1.html

OK, this one is going to take some work, so I'm putting it off for now. We can go to beta without it, I think. The problem is that the prescripts aren't placed properly when the base has a line break, but since most uses of prescripts don't have breakable bases, I think this should not be a major problem for now.

--------------------------------------------

UI/zoom-box-1.html

This is fixed in develop. (It is the incorrect measurement of <math> widths again.)

--------------------------------------------

> Frédéric Wang
> maths-informatique-jeux.com/blog/frederic
>
> --
> You received this message because you are subscribed to the Google Groups "MathJax Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to mathjax-dev...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Frédéric WANG]

Here are the results for IE. Some remarks:

- I used the packed version and integrated the mlabeled fix.
- There seems to be many Javascript errors, most of them in the TeX
input jax.
- IE was upgraded to IE10 on the test machine but there are issues with
MathPlayer so I uninstalled it before running the tests. In the Quirks
mode, I still get the warning about MathPlayer unable to start (weird??)
so I didn't run that mode. I didn't try with the IE10 mode (I need to
make the scripts aware of that mode).

IE7:

http://mathjaxtest.s3.amazonaws.com/v2.1-candidate/2013-04-30/Windows_MSIE_IE7_STIX_HTML-CSS-2.html.gz
http://mathjaxtest.s3.amazonaws.com/v2.1-candidate/2013-04-30/Windows_MSIE_IE7_TeX_HTML-CSS.html.gz

IE8:

http://mathjaxtest.s3.amazonaws.com/v2.1-candidate/2013-04-30/Windows_MSIE_IE8_STIX_HTML-CSS.html.gz
http://mathjaxtest.s3.amazonaws.com/v2.1-candidate/2013-04-30/Windows_MSIE_IE8_TeX_HTML-CSS-2.html.gz

IE9:

http://mathjaxtest.s3.amazonaws.com/v2.1-candidate/2013-04-30/Windows_MSIE_IE9_STIX_HTML-CSS.html.gz
http://mathjaxtest.s3.amazonaws.com/v2.1-candidate/2013-04-30/Windows_MSIE_IE9_TeX_HTML-CSS.html.gz
http://mathjaxtest.s3.amazonaws.com/v2.1-candidate/2013-04-30/Windows_MSIE_IE9_TeX_SVG.html.gz

[Davide P. Cervone]

> - There seems to be many Javascript errors, most of them in the TeX input jax.

There was an extra comma, which I've removed. I still do more tests with IE tomorrow, but I did manage to find that one. I've merged the change to develop and repacked and recombined. That includes all the corrections that I did based on the Firefox output. Still looking through the others to see what differences there are from that, but it looks like that is the major chunk.

Thanks for running the tests!

Davide

[Peter Krautzberger]

> Thanks for running the tests!

Second that! Great job.

[Frédéric WANG]

> API/Hub/messagehook-1.html
> The failure is due to the presence of _moz-math-font-style="italic"
in the source MathML. (This isn't removed by MathJax until the
conversion from the original text to the internal format.) So I guess
the reference value has to change until Firefox no longer applied these
values. Alternatively, you can remove them in your xMathJaxConfig routine.

=> marked fails-if(Firefox)

> AsciiMathToMathML/issue384.html
> The NativeMML output automatically adds the outer <mrow> for Firefox,
so there is no need to include it in the reference file. (It will be
added when the Math is output for the reference.) So removing that row
should resolve the problem.

=> Test Updated

> Configuration/Hub/v1.0-compatible-1.html
> Test should be removed (or disabled) since v1.0-warning.js is now
removed.

=> Test disabled

> Configuration/Hub/errorSettings-1.html
> Configuration/TeX/MAXBUFFER-1.html
> Configuration/TeX/MAXMACROS-1.html
> LaTeXToMathML/macro/macro-4.html
> LaTeXToMathML/references/label-1.html

> LaTeXToMathML/limits-4.html
> LaTeXToMathML/primes-3.html
> Parsing/issue228.html
> I am not able to reproduce the error (the tests work by hand). These
all test the generation of error messages, and since it seems that "new
Error()" is trapped by the test framework, that may be the cause of
this. MathJax does use "new Error()" internally, so that could be the
problem.

As I said yesterday, I changed the way the testing framework detects the
[Math Processing Error]. In the past, the testing framework modified the
MathJax error message, so that a HTML snippet with Javascript code
raising an exception was inserted and so the normal js error trapping
was used. Now, that we have a "Math Processing Error" signal, I directly
listened it. However, that does not seem to work very well for tests
where the processing error is on purpose, so I need to improve that.

> LaTeXToMathML/issue236.html

> (The ref-test for LaTeXToMathML/issue236.html will need to be
changed, as negative dimens are now accepted (but mostly ignored).)

It seems that I forgot to update that reftest. I replaced the reference
by "0"

> MathMLToDisplay/Presentation/CSS/mspace/mspace-02.html
> Because the MathML spec says that the linebreak attribute is to be
ignored if one of the dimensional attributes is present, the ref-test
should be changed. All the linebreak="newline" misplaces should NOT
have width="0" set explicitly.

=> Test Updated

PS: I also enabled the Localization tests.

[Davide P. Cervone]

> As I said yesterday, I changed the way the testing framework detects the [Math Processing Error]. In the past, the testing framework modified the MathJax error message, so that a HTML snippet with Javascript code raising an exception was inserted and so the normal js error trapping was used. Now, that we have a "Math Processing Error" signal, I directly listened it. However, that does not seem to work very well for tests where the processing error is on purpose, so I need to improve that.

Not all of the affected tests are ones where there is a [Math Processing Error]. Some are just ones where there is a TeX error that should end up as an error message displayed properly within the output. So I'm wondering if there isn't something more going on, as no math processing error should occur. But if you think it is something you changed in the framework, I'm happy to let you work it out.

Davide

[Frédéric WANG]

On 01/05/2013 15:00, Davide P. Cervone wrote:
> Not all of the affected tests are ones where there is a [Math
> Processing Error]. Some are just ones where there is a TeX error that
> should end up as an error message displayed properly within the
> output. So I'm wondering if there isn't something more going on, as no
> math processing error should occur. But if you think it is something
> you changed in the framework, I'm happy to let you work it out. Davide

I'm just checking that right now, and apparently I listen both "Math
Processing Error" and "TeX Jax - parse error" (so that I can now detect
unexpected TeX parsing errors too). I'm modifying this to tolerate a
maximum number of expected error signals before actually reporting an
error to the framework. That will be up to the test pages to set this
maximum number, if necessary.

[Davide P. Cervone]

OK, sounds good. That does seem to account for the problems that I was seeing. I'm glad it is not something harder to handle.

Davide

[Frédéric WANG]

OK, I've pushed the changes and now all these tests pass on
Opera/Firefox/Chrome Linux.

Note that I updated testsuite/header.js-tpl so you need to regenerate
header.js in order to make the tests work properly.

On 01/05/2013 15:11, Davide P. Cervone wrote:
> OK, sounds good. That does seem to account for the problems that I was seeing. I'm glad it is not something harder to handle.
>
> Davide
>
>

[Davide P. Cervone]

Thanks. I've been looking through the other test runs (other browsers and os's). So far nothing of any real consequence. Opera is filing some tests because of the mfenced code. Remember that mfenced is used in Opera where mrow+mo is used in others, so the reference files need to be different. Perhaps there need to be two tests, one for Opera (skipped by everyone else) and one for everyone else (skipped by opera).

Davide

On May 1, 2013, at 10:23 AM, Frédéric WANG wrote:

> OK, I've pushed the changes and now all these tests pass on Opera/Firefox/Chrome Linux.
>
> Note that I updated testsuite/header.js-tpl so you need to regenerate header.js in order to make the tests work properly.
>
> On 01/05/2013 15:11, Davide P. Cervone wrote:
>> OK, sounds good. That does seem to account for the problems that I was seeing. I'm glad it is not something harder to handle.
>>
>> Davide
>>
>>
>
> --

[Frédéric WANG]

On 01/05/2013 16:29, Davide P. Cervone wrote:
> Thanks. I've been looking through the other test runs (other browsers and os's). So far nothing of any real consequence. Opera is filing some tests because of the mfenced code. Remember that mfenced is used in Opera where mrow+mo is used in others, so the reference files need to be different. Perhaps there need to be two tests, one for Opera (skipped by everyone else) and one for everyone else (skipped by opera).
>
> Davide

OK, I thought I verified it passed the LaTeXToMathML tests when I was
working on the branch but I didn't run all the other tests. I don't
really want to do a special case for Opera. I can just mark them
"fails-if(Opera)" for now and update this later when Opera switches to
Blink.

[Frédéric WANG]

BTW, if that's OK, I'm about to execute the tests again on Linux to see
if things have improved.

[Davide P. Cervone]

Yes, that's great. I've made all the changes that I know of for now. I'm just looking for more differences, but haven't seen any that need attention.

Davide

On May 1, 2013, at 10:33 AM, Frédéric WANG wrote:

> BTW, if that's OK, I'm about to execute the tests again on Linux to see if things have improved.
>
> --

[Davide P. Cervone]

> OK, I thought I verified it passed the LaTeXToMathML tests when I was working on the branch but I didn't run all the other tests. I don't really want to do a special case for Opera. I can just mark them "fails-if(Opera)" for now and update this later when Opera switches to Blink.

OK. It looks like it is just two anyway:

LaTeXToMathML/layout/newline-1.html
LaTeXToMathML/mhchem/advanced-2.html

Davide

[Davide P. Cervone]

It looks like Configuration/Hub/issue163.html can be removed, since the configuration warning is no longer being used.

Davide

On May 1, 2013, at 10:33 AM, Frédéric WANG wrote:

> BTW, if that's OK, I'm about to execute the tests again on Linux to see if things have improved.
>
> --