MathJax V2.0 candidate - Testing
Frédéric WANG
Linux. Using several combinations of fonts (MathJax or STIX) and output
modes (HTML-CSS and SVG):
http://devel.mathjax.org/testing/web/results/v2.0-candidate/2012-01-31/MathMLToDisplay/
Frédéric WANG
devel.mathjax.org/testing/web/results/v2.0-candidate/2012-02-01/LaTeXToMathML/
Firefox:
There is only one remaining unexpected failure, which is again the
"Can't make callback from given data". Note that this exception seems to
happen with any page, just one or two seconds after MathJax completes.
I'm guessing that they are generally not caught by the testing instance
because it moves to the next test before the exception is raised.
Opera and Chrome:
All look OK, except that sometimes the attributes on the <math> element
are not in the same order as the references, but that's not a bug in
MathJax.
IE9 (Quirks mode)
I have verified the errors, most of them are due to the fact that the
xmlns attribute is lacking on the <math> element.
The other errors indicate serialization failures in the testing
framework that may be due to bugs in MathJax. I'll have to analyse this
further.
LaTeXToMathML/above-below/subarray-1.html
LaTeXToMathML/above-below/substack-1.html
LaTeXToMathML/layout/shove-1.html
LaTeXToMathML/references/label-1.html
LaTeXToMathML/symbols/largeops-1.html
LaTeXToMathML/limits-1.html
LaTeXToMathML/limits-3.html
Safari
I have not verified all, but most of the errors seem to be because xmlns
attribute is lacking on the <math> element (may be similar to the
problem you worked around in Chrome).
Davide P. Cervone
>
> There is only one remaining unexpected failure, which is again the
> "Can't make callback from given data". Note that this exception
> seems to happen with any page, just one or two seconds after MathJax
> completes. I'm guessing that they are generally not caught by the
> testing instance because it moves to the next test before the
> exception is raised.
OK, I found it. It turns out that Gecko adds an extra parameter to
the function that it calls, and the function I was having setTimeout
call took an optional argument that is supposed to be a callback. So
in FF, it was trying to make Gecko's extra parameter into a callback,
which was causing the error. I've taken care of it.
> Opera and Chrome:
>
> All look OK, except that sometimes the attributes on the <math>
> element are not in the same order as the references, but that's not
> a bug in MathJax.
Right.
> IE9 (Quirks mode)
>
> I have verified the errors, most of them are due to the fact that
> the xmlns attribute is lacking on the <math> element.
> The other errors indicate serialization failures in the testing
> framework that may be due to bugs in MathJax. I'll have to analyse
> this further.
>
> LaTeXToMathML/above-below/subarray-1.html
> LaTeXToMathML/above-below/substack-1.html
> LaTeXToMathML/layout/shove-1.html
> LaTeXToMathML/references/label-1.html
> LaTeXToMathML/symbols/largeops-1.html
> LaTeXToMathML/limits-1.html
> LaTeXToMathML/limits-3.html
I will look into these later.
> Safari
>
> I have not verified all, but most of the errors seem to be because
> xmlns attribute is lacking on the <math> element (may be similar to
> the problem you worked around in Chrome).
I've fixed the xmlns attribute for ALL browsers (not just Chrome) so
this should clear these up, and also the same problems in IE.
So I think that just leaves the handfull of IE9 issues to look at.
Davide
Frédéric WANG
http://devel.mathjax.org/testing/web/results/v2.0-candidate/2012-02-01/LaTeXToMathML-2/
New results for all tests (Opera and Firefox on Linux):
http://devel.mathjax.org/testing/web/results/v2.0-candidate/2012-02-01/Linux_Opera_default_TeX.html.gz
http://devel.mathjax.org/testing/web/results/v2.0-candidate/2012-02-01/Linux_Firefox_default_STIX.html.gz
Davide P. Cervone
>
> http://devel.mathjax.org/testing/web/results/v2.0-candidate/2012-02-01/LaTeXToMathML-2/
Great. These look very good, now, and I don't see anything that needs
addressing there.
> New results for all tests (Opera and Firefox on Linux):
>
> http://devel.mathjax.org/testing/web/results/v2.0-candidate/2012-02-01/Linux_Opera_default_TeX.html.gz
> http://devel.mathjax.org/testing/web/results/v2.0-candidate/2012-02-01/Linux_Firefox_default_STIX.html.gz
The Firefox looks pretty good, and I will go through the ones that are
failing (I had already started on the previous batch, but will go on
to this set).
Many of the Opera failures seem to be due to differences in the black
area at the bottom of the images that are not part of the MathJax
output. It looks like random noise. Can you do anything about that
in the tests? It is difficult to go through these images to see if it
is MathJax or just the junk at the bottom that are the problems.
Davide
Frédéric WANG
> Many of the Opera failures seem to be due to differences in the black
> area at the bottom of the images that are not part of the MathJax
> output. It looks like random noise. Can you do anything about that
> in the tests? It is difficult to go through these images to see if it
> is MathJax or just the junk at the bottom that are the problems.
takes screenshot. To workaround it, I added an instruction to cut the
bottom of the image after receiving the screenshot from the OperaDriver.
Here are the new results:
Davide P. Cervone
to fix.
Davide
Frédéric WANG
HTML-CSS/SVG outputs. They should appear in a moment here:
http://devel.mathjax.org/testing/web/results/v2.0-candidate/2012-02-02/
Davide P. Cervone
Davide P. Cervone
Davide P. Cervone
Davide P. Cervone
Davide P. Cervone
Frédéric WANG
> The issue here is that MathJax now loads the Menu and Zoom code after
a short delay once the initial typesetting pass has occurred. The Menu
is loaded 1 second after typesetting, and Zoom is loaded 2 seconds
after. These actions cause put the loading messages into the message
area. Your delay=900 plus tolerance=100 means you are picking up the
Menu load message in your second test, so it is failing. You can fix
this by changing the delay so that it misses that message, or by adding
MathMenu.js and MathZoom.js to the extensions array of the configuration.
=> Fixed by adding MathMenu.js and MathZoom.js to the extensions array.
> Configuration/Contexts/svg-1a.html
> Configuration/Contexts/svg-1b.html
> Looks like the missing 1px at the top for both of these.
=> Fixed.
> Parsing/missing-brace-1.html
> The difference here is due to the new class information that was
added in V2.0.
=> Fixed.
> MathMLToDisplay/issue162.html
> I think the test is in error. The red rectangle is BEFORE the
visible expression, so should be BEHIND it, so not hidden. (The
HTML-CSS output gets this wrong because the background color has
position CSS while the equation doesn't.)
=> Fixed, using div elements positioned by CSS.
> Configuration/FontWarnings/fadeout-1.html
> Looks like the two images have different opacities, but the test code
looks good, so I don't see why. The only thing I can think of is that
the font warning does require the FontWarning extension to be loaded,
which is asynchronous, so it might be that that is causing a delay in
the countdown for the test file (it does seem to be one opacity step too
soon). So it might be good to force that extension to load before
hand. I.e., add
> ["Require",MathJax.Ajax,"[MathJax]/extensions/FontWarnings.js"],
> to the front of the MathJax.Hub.Queue() in postMathJax(), or add
FontWarnings.js to the extensions array of the configuration.
=> FontWarnings.js is already added to the extensions array of the
configuration, so I don't think that's the problem. I just ran the test
five time, it fails once and succeeded four times. I think the error
tolerance was too small, so I've increased it. Now I'm testing an
opacity in an interval of 2 seconds. I ran the test again 50 times with
this new config and it never failed.
> Configuration/FontWarnings/removeAfter-1a.html
> This may also be due to a timing issue with loading the warning code
(the picture is taken before the file is loaded and the warning is
issued). The same solution as above may take care of this.
=> I changed removeAfter to happen at t=2s instead of 1=s. Hope that it
fixes the issue.
> Configuration/HTML-CSS/tooltip-1.html (four instances)
Yes, I noticed that the size was too large but I was not sure whether it
was a bug or if I was calling the private interface incorrectly. I
suspect these too large rectangles make Selenium fail to take
screenshot, because of a lack of memory. I just ran the tooltip tests on
Firefox Linux and they all pass now.
> Configuration/Hub/menuSettings/zoom-1.html (three instances)
> The event-handling code has been completely rewritten, and there is
no longer a Mousemove function in the MathZoom code. You might be able
to replace that with the new Hover() method (I haven't tried it).
Just replacing MouseOver by Hover seems to work. All zoom tests pass
with Opera. The last one, zoomConfig=Hover&zoomTrigger=Hover fails on
Firefox but it was already marked "fails" before.
> Configuration/MathMenu/styles-1.html
> This comes from the fact that the MathEvents extension (which defines
the routine that FF is complaining about) hasn't been loaded. That is
because there is no actual math on the page, so there was no need for
it, and MathJax didn't load it. If you add some math to the page, that
should clear that up. Alternatively, you can force MathEvents to load
by adding it to the extensions array in the configuration.
=> Fixed by adding MathEvents.
> Configuration/MMLorHTML/prefer-3.html
> The defaults have changed for MMLorHTML. Firefox now defaults to
HTML-CSS rather than MathML.
=> Fixed.
> MathMLToDisplay/Presentation/TokenElements/mglyph/rec-mglyph1.html
> I don't think the test is correct. MathJax doesn't produce mtext
elements for missing characters, for one thing. I also wonder if you
have "Curlz MT" on the test machine (that test passes for me, because I
do have it).
The idea is to test various mglyph with fonts that may or may not exit
on the machine (my-braid-font is really unlikely to be installed while
Arial is likely to be). It verifies the presence of the character if the
glyph is found or of the alttext when it is not found. Note that this
test uses getElementByClassName to find the HTML span's with class
"mglyph" and "mtext" produced by MathJax. This is a bit fragile, it was
broken and I fixed it but I'm open to a better solution to find the
character/alttext.
I've also removed the test for the SVG output jax, since it behaves
differently.
> MathMLToDisplay/Presentation/TablesAndMatrices/mtable/rowalign-2.html
> The rows in MathJax's tables have a default height and depth that are
the same as a standard line of text. (This is so that rows of arrays
will all have the same height and depth even if there are no asenders or
descenders). That amounts to about .8em height and .2em depth in
general. So the align to bottom is actually to the bottom of the depth,
.2em lower than the baseline, and that accounts for the vertical
difference in your two outputs. Using rowalign="baseline" should make
the test the same as the reference. Alternatively, you could provide
something with more depth in both figures so that their depths match
up. E.g., add depth="1ex" to all the colored bars.
Fixed by using rowalign="baseline".
> MathMLToDisplay/Presentation/TokenElements/mi/mi4.html
> MathJax v2.0 with its web fonts uses a text italic font rather than
math italics for <mtext mathvariant="italic">, so italic mtext is not
the same as <mi> with single letter. So for example <mtext
mathvariant="italic">different</mtext> will have the correct spacing for
the f's. MathJax 2.0 also does italic correction for <mi> elements, but
not for <mtext>, so that also changes the spacing for these. The italic
lower-case "f" is very different in these two fonts, so your results
will be different here. Perhaps using a different letter with less
spacing difference in the two fonts would work better.
I replace by a "g" and that seems to work better.
Frédéric WANG
API/ElementJax/Reprocess-2.htmlTest is not appropriate for HTML-CSS or SVG output, since it looks up the mspace element, which is not part of the HTML-CSS or SVG output. Also, changing the point size of the font shouldn't change the dimensions in px.
API/ElementJax/Text-2.htmlAPI/Hub/Reprocess-2.htmlAPI/Hub/Reprocess-3.htmlAPI/Hub/Update-1.htmlTest is not appropriate for HTML-CSS or SVG output, since it looks up the mspace element, which is not part of the HTML-CSS or SVG output. These tests could possibly be fixed by looking at the width of the containing div if you made it display:inline-block or positioned with width:auto.
For the first one, MathJax HTML-CSS output converts the "px" into relative unit "em", so changing the point size does change the size in that case (again, this test is bad because it assumes a particular behavior of MathJax). The test passes on Firefox for me. It does not on Opera, apparently because offsetWidth and offsetHeight are incorrect.
I'll try your suggestion.
Frédéric WANG
When I execute the test I get "FALSE is not a function MathMenu.js, line
231". This does not happen when I load the page manually.
Also, when I click on the page, I now get "MENU.jax is undefined,
MathMenu.js, line 244".
> LaTeXToMathML/symbols/symbols-4.html
> LaTeXToMathML/symbols/symbols-4.html
The right corners seem to have changed since last time. Is it on purpose?
> MathMLToDisplay/Presentation/GeneralLayout/menclose/menclose-2e.html
> MathMLToDisplay/Presentation/GeneralLayout/menclose/menclose-2f.html
I've increased the stroke-width of the SVG drawing hiding the menclose
drawing, but I think the change was due to the 1px above/below the
MathML that shifts the menclose.
> MathMLToDisplay/Presentation/TokenElements/ms/ms1.html
> MathMLToDisplay/Presentation/TokenElements/ms/msAdisplaystyle2.html
> MathMLToDisplay/Presentation/TokenElements/ms/msAtoken4.html
> MathMLToDisplay/Presentation/TokenElements/ms/msAtoken5.html
> MathMLToDisplay/Presentation/TokenElements/ms/msScolorscope6.html
> MathMLToDisplay/Presentation/TokenElements/ms/msSinheritance7.html
> The reference file should use mathvariant="monospace" rather than
style="font-family:monospace" since the browser's monospace font is not
the same as the math monospace font. Several tests produced math
processing errors, which I have fixed. The font size problem for
absolute font sizes still needs to be fixed.
Using mathvariant="monospace" seems to fail in HTML-CSS output.
BTW, I've added the rule rect { shape-rendering: crispEdges; } that
seems to work on Firefox/Opera/Webkit. I'll run the tests later to see
if we get better results.
Frédéric WANG
FontWarnings.js seems to only consider the HTML-CSS output Jax, not the
SVG one. Is it intentional? Should I skip this test for SVG?
BTW, I think a space is missing at the end of the first string here (in
FontWarnings.js)
"on this page. These take time to download, so the page would",
"render faster if you installed math fonts directly in your ",
"wouldrender" is displayed.
Frédéric WANG
http://devel.mathjax.org/testing/web/results/v2.0-candidate/2012-02-06/
I'm still fixing some issues in the test pages.
Davide P. Cervone
> > Looks like the two images have different opacities, but the test
> code looks good, so I don't see why. The only thing I can think of
> is that the font warning does require the FontWarning extension to
> be loaded, which is asynchronous, so it might be that that is
> causing a delay in the countdown for the test file (it does seem to
> be one opacity step too soon). So it might be good to force that
> extension to load before hand. I.e., add
>
> > ["Require",MathJax.Ajax,"[MathJax]/extensions/FontWarnings.js"],
>
> > to the front of the MathJax.Hub.Queue() in postMathJax(), or add
> FontWarnings.js to the extensions array of the configuration.
>
> => FontWarnings.js is already added to the extensions array of the
> configuration, so I don't think that's the problem. I just ran the
> test five time, it fails once and succeeded four times. I think the
> error tolerance was too small, so I've increased it. Now I'm testing
> an opacity in an interval of 2 seconds. I ran the test again 50
> times with this new config and it never failed.
Great. I guess I had been looking at too many tests, and got the
issue wrong here. Glad you got it to work another way.
> > Configuration/FontWarnings/removeAfter-1a.html
> > This may also be due to a timing issue with loading the warning
> code (the picture is taken before the file is loaded and the warning
> is issued). The same solution as above may take care of this.
>
> => I changed removeAfter to happen at t=2s instead of 1=s. Hope that
> it fixes the issue.
OK, sounds good.
> > Configuration/HTML-CSS/tooltip-1.html (four instances)
>
> Yes, I noticed that the size was too large but I was not sure
> whether it was a bug or if I was calling the private interface
> incorrectly. I suspect these too large rectangles make Selenium fail
> to take screenshot, because of a lack of memory. I just ran the
> tooltip tests on Firefox Linux and they all pass now.
Great!
> > Configuration/Hub/menuSettings/zoom-1.html (three instances)
> > The event-handling code has been completely rewritten, and there
> is no longer a Mousemove function in the MathZoom code. You might
> be able to replace that with the new Hover() method (I haven't tried
> it).
>
> Just replacing MouseOver by Hover seems to work. All zoom tests pass
> with Opera. The last one, zoomConfig=Hover&zoomTrigger=Hover fails
> on Firefox but it was already marked "fails" before.
OK, I'll look at FF for this, but don't think it is crucial for now.
> > MathMLToDisplay/Presentation/TokenElements/mglyph/rec-mglyph1.html
> > I don't think the test is correct. MathJax doesn't produce mtext
> elements for missing characters, for one thing. I also wonder if
> you have "Curlz MT" on the test machine (that test passes for me,
> because I do have it).
>
> The idea is to test various mglyph with fonts that may or may not
> exit on the machine (my-braid-font is really unlikely to be
> installed while Arial is likely to be). It verifies the presence of
> the character if the glyph is found or of the alttext when it is not
> found. Note that this test uses getElementByClassName to find the
> HTML span's with class "mglyph" and "mtext" produced by MathJax.
> This is a bit fragile, it was broken and I fixed it but I'm open to
> a better solution to find the character/alttext.
OK, I guess I didn't look closely enough to see that it would work
with HTML-CSS. The SVG jax can be told to retain the MathML structure
in a similar way, so it could probably be made to work there as well.
> I've also removed the test for the SVG output jax, since it behaves
> differently.
Fine for now.
> > MathMLToDisplay/Presentation/TokenElements/mi/mi4.html
> > MathJax v2.0 with its web fonts uses a text italic font rather
> than math italics for <mtext mathvariant="italic">, so italic mtext
> is not the same as <mi> with single letter. So for example <mtext
> mathvariant="italic">different</mtext> will have the correct spacing
> for the f's. MathJax 2.0 also does italic correction for <mi>
> elements, but not for <mtext>, so that also changes the spacing for
> these. The italic lower-case "f" is very different in these two
> fonts, so your results will be different here. Perhaps using a
> different letter with less spacing difference in the two fonts would
> work better.
>
> I replace by a "g" and that seems to work better.
OK, great.
Thanks for you work on these!
Davide
Frédéric WANG
but they were applied before the last test execution so are not visible
in the results)
> Configuration/Hub/menuSettings/zoom-1.html
> Configuration/Hub/menuSettings/zscale-1.html
=> OK, I modified these tests to take into account the SVG ouput case.
I think zscale-1.html passes for me with the SVG output but not the
HTML-CSS output.
> MathMLToDisplay/General/Colors/mathbackground-6.html
> Looks like the anti-aliasing problem again. Not much I can do
about. There are attributes that are supposed to control antialiasing,
but the browsers don't seem to respect them. Note also that your top
and left CSS are not being honored since they have no units.
=> Seems to be fixed by disabling anti-aliasing. I removed the top/left
properties.
> MathMLToDisplay/General/GenAttribs/href1.html
> MathMLToDisplay/General/GenAttribs/href2.html
> MathMLToDisplay/General/GenAttribs/href3.html
> MathMLToDisplay/General/GenAttribs/link-1.html
> MathMLToDisplay/General/GenAttribs/link-2.html
> MathMLToDisplay/Presentation/TokenElements/mglyph/mglyph3.html
> MathMLToDisplay/Presentation/TokenElements/mglyph/mglyph_aspect_gif.html
> MathMLToDisplay/Presentation/TokenElements/mglyph/mglyph_aspect.html
> MathMLToDisplay/Presentation/TokenElements/mglyph/mglyph_stretched.html
>
MathMLToDisplay/Presentation/TokenElements/mglyph/mglyph_valignbottom.html
>
MathMLToDisplay/Presentation/TokenElements/mglyph/mglyph_valignmiddle.html
> MathMLToDisplay/Presentation/TokenElements/mglyph/mglyph_valigntop.html
=> Should I mark these tests "fails" in SVG output mode?
> MathMLToDisplay/Presentation/CSS/mspace/mspace-02.html
> This is marked as known fail, but it now passes (there was a problem,
but I just fixed it). Also, you need to add
> gConfigObject["SVG"] = {linebreaks : { automatic: true } };
> since it only had HTML-CSS linebreaks.
=> Config added. For the moment, I did not update the test failure info
to take into account the fixes in MathJax v2.0. In particular many tests
appear "UNEXPECTED-PASS". Maybe I can do it now, so we will better see
which are not fixed yet (if any)?
> MathMLToDisplay/Presentation/TablesAndMatrices/mtable/rowlines-3-2.html
> The antialiasing on the single line versus the overprinted line are
different (because the partial pixels add up to darker values)
=> Disabling antiliasing for lines make them disappear. So I'll have to
come with another idea for this test...
> MathMLToDisplay/Presentation/CSS/munder/munder-11.html
> The phantom 1 is higher than the x, so pushes the x farther below.
(Using phantom x's, or a 1 instead of the x, would help.)
> MathMLToDisplay/Presentation/CSS/munderover/munderover-11.html
> The phantom 1 is higher than the s, so pushes the s farther below.
These are tests from the W3C test suite, but I agree with you that they
do not seem correct...
I replaced the one's by underscores.
Davide P. Cervone
SVG paths, which it always has available. There no need to install
fonts, and no benefit from doing so. The only advantage would be if
the math uses characters that aren't known to it (for which it doesn't
have paths), then having STIX installed locally would help.
In any case, no one is using the FontWarnings extension as far as I
know, so it is not a big issue.
I have fixed the space problem. Thanks for the catch.
Davide
Frédéric WANG
> The SVG renderer doesn't use system fonts or web fonts, rather it uses
> SVG paths, which it always has available. There no need to install
> fonts, and no benefit from doing so. The only advantage would be if
> the math uses characters that aren't known to it (for which it doesn't
> have paths), then having STIX installed locally would help.
>
> In any case, no one is using the FontWarnings extension as far as I
> know, so it is not a big issue.
>
> I have fixed the space problem. Thanks for the catch.
>
> Davide
I'll skip all the tests that rely on FontWarnings when the SVG output is
used.
Davide P. Cervone
Davide P. Cervone
>
> When I execute the test I get "FALSE is not a function MathMenu.js,
> line 231". This does not happen when I load the page manually.
> Also, when I click on the page, I now get "MENU.jax is undefined,
> MathMenu.js, line 244".
Are you using the new version that loads MathEvents.js first? If so,
you should not be getting the error about FALSE being undefined. I'm
wondering if you added some math to the page it would help.
As for the MENU.jax being undefined, that is because you are calling
MathJax.Menu.menu.Post() without its being attached to any math
element (normally this is called from an event handler that sets up
the MENU.jax value to point to the element jax of the math where the
menu has been requested). When you click anywhere on the page, a
handler runs that looks up the jax that was associated to the menu,
but that value isn't there. This is a side-effect of the setup in
this test file, and won't occur in practice.
Is it important than a click be processed after the menu is shown for
this test?
> > LaTeXToMathML/symbols/symbols-4.html
> > LaTeXToMathML/symbols/symbols-4.html
>
> The right corners seem to have changed since last time. Is it on
> purpose?
Yes. The new locations are U+231C, U+231D, U+231E and U+231F, which
are the correct locations for the math corners (rather than the box
drawing locations they were in before).
> > MathMLToDisplay/Presentation/GeneralLayout/menclose/menclose-2e.html
> > MathMLToDisplay/Presentation/GeneralLayout/menclose/menclose-2f.html
>
> I've increased the stroke-width of the SVG drawing hiding the
> menclose drawing, but I think the change was due to the 1px above/
> below the MathML that shifts the menclose.
OK.
> > MathMLToDisplay/Presentation/TokenElements/ms/ms1.html
> > MathMLToDisplay/Presentation/TokenElements/ms/msAdisplaystyle2.html
> > MathMLToDisplay/Presentation/TokenElements/ms/msAtoken4.html
> > MathMLToDisplay/Presentation/TokenElements/ms/msAtoken5.html
> > MathMLToDisplay/Presentation/TokenElements/ms/msScolorscope6.html
> > MathMLToDisplay/Presentation/TokenElements/ms/msSinheritance7.html
> > The reference file should use mathvariant="monospace" rather than
> style="font-family:monospace" since the browser's monospace font is
> not the same as the math monospace font. Several tests produced
> math processing errors, which I have fixed. The font size problem
> for absolute font sizes still needs to be fixed.
I think I have the font size problem taken care of.
> Using mathvariant="monospace" seems to fail in HTML-CSS output.
OK, I have fixed that. The handling of the font was different in SVG
and HTML-CSS, and I've made them both be the same.
> BTW, I've added the rule rect { shape-rendering: crispEdges; } that
> seems to work on Firefox/Opera/Webkit. I'll run the tests later to
> see if we get better results.
Good to know. I'll see about adding that to MathJax's style settings,
as I was unhappy with the antialiasing for the colored backgrounds and
such. I don't remember what attributes I had tried, but they didn't
work at the time. Of course, that was a year ago, now, so perhaps
things have improved.
Davide
Davide P. Cervone
> > Configuration/Hub/menuSettings/zscale-1.html
>
> => OK, I modified these tests to take into account the SVG ouput case.
> I think zscale-1.html passes for me with the SVG output but not the
> HTML-CSS output.
It looks OK in HTML-CSS to me (by eye). Can you say what is going
wrong for you?
> > MathMLToDisplay/General/Colors/mathbackground-6.html
> > Looks like the anti-aliasing problem again. Not much I can do
> about. There are attributes that are supposed to control
> antialiasing, but the browsers don't seem to respect them. Note
> also that your top and left CSS are not being honored since they
> have no units.
>
> => Seems to be fixed by disabling anti-aliasing. I removed the top/
> left properties.
Sounds good.
> > MathMLToDisplay/General/GenAttribs/href1.html
> > MathMLToDisplay/General/GenAttribs/href2.html
> > MathMLToDisplay/General/GenAttribs/href3.html
> > MathMLToDisplay/General/GenAttribs/link-1.html
> > MathMLToDisplay/General/GenAttribs/link-2.html
> > MathMLToDisplay/Presentation/TokenElements/mglyph/mglyph3.html
> > MathMLToDisplay/Presentation/TokenElements/mglyph/
> mglyph_aspect_gif.html
> > MathMLToDisplay/Presentation/TokenElements/mglyph/mglyph_aspect.html
> > MathMLToDisplay/Presentation/TokenElements/mglyph/
> mglyph_stretched.html
> > MathMLToDisplay/Presentation/TokenElements/mglyph/
> mglyph_valignbottom.html
> > MathMLToDisplay/Presentation/TokenElements/mglyph/
> mglyph_valignmiddle.html
> > MathMLToDisplay/Presentation/TokenElements/mglyph/
> mglyph_valigntop.html
>
> => Should I mark these tests "fails" in SVG output mode?
Yes, I think so. I'm not planning to do the background image support
any time soon in SVG.
> > MathMLToDisplay/Presentation/CSS/mspace/mspace-02.html
> > This is marked as known fail, but it now passes (there was a
> problem, but I just fixed it). Also, you need to add
> > gConfigObject["SVG"] = {linebreaks : { automatic: true } };
> > since it only had HTML-CSS linebreaks.
>
> => Config added. For the moment, I did not update the test failure
> info to take into account the fixes in MathJax v2.0. In particular
> many tests appear "UNEXPECTED-PASS". Maybe I can do it now, so we
> will better see which are not fixed yet (if any)?
Yes, that might be good to do.
I have not gone through any of the known-fail tests to see what might
be the issues. Perhaps that is something to do in the future.
> > MathMLToDisplay/Presentation/TablesAndMatrices/mtable/
> rowlines-3-2.html
> > The antialiasing on the single line versus the overprinted line
> are different (because the partial pixels add up to darker values)
>
> => Disabling antiliasing for lines make them disappear. So I'll have
> to come with another idea for this test...
Disappointing. I don't have any suggestions.
> > MathMLToDisplay/Presentation/CSS/munder/munder-11.html
> > The phantom 1 is higher than the x, so pushes the x farther
> below. (Using phantom x's, or a 1 instead of the x, would help.)
> > MathMLToDisplay/Presentation/CSS/munderover/munderover-11.html
> > The phantom 1 is higher than the s, so pushes the s farther below.
>
> These are tests from the W3C test suite, but I agree with you that
> they do not seem correct...
> I replaced the one's by underscores.
OK, thanks.
Davide
Davide P. Cervone
the colored boxes weren't covering the table properly. (A work-around
to an Opera display bug caused bad side-effects.)
Davide
On Feb 6, 2012, at 8:36 AM, Frédéric WANG wrote:
> New results:
>
> http://devel.mathjax.org/testing/web/results/v2.0-candidate/
> 2012-02-06/
>
Frédéric WANG
> New results:
>
> http://devel.mathjax.org/testing/web/results/v2.0-candidate/2012-02-06/
>
http://devel.mathjax.org/testing/web/results/v2.0-candidate/2012-02-06/Windows_Chrome_default_STIX.html.gz
http://devel.mathjax.org/testing/web/results/v2.0-candidate/2012-02-06/Windows_Chrome_default_STIX-SVG.html.gz
Davide P. Cervone
Frédéric WANG
> Are you using the new version that loads MathEvents.js first? If so,
> you should not be getting the error about FALSE being undefined. I'm
> wondering if you added some math to the page it would help.
>
> As for the MENU.jax being undefined, that is because you are calling
> MathJax.Menu.menu.Post() without its being attached to any math
> element (normally this is called from an event handler that sets up
> the MENU.jax value to point to the element jax of the math where the
> menu has been requested). When you click anywhere on the page, a
> handler runs that looks up the jax that was associated to the menu,
> but that value isn't there. This is a side-effect of the setup in
> this test file, and won't occur in practice.
>
> Is it important than a click be processed after the menu is shown for
> this test?
>
update the reference page too. Sorry about that.
No, I don't need to process a click after the menu is shown, I just
wanted to be sure that it was because I call the private interface
directly and that it was not a MathJax bug.
>> > LaTeXToMathML/symbols/symbols-4.html
>> > LaTeXToMathML/symbols/symbols-4.html
>>
>> The right corners seem to have changed since last time. Is it on
>> purpose?
>
> Yes. The new locations are U+231C, U+231D, U+231E and U+231F, which
> are the correct locations for the math corners (rather than the box
> drawing locations they were in before).
>
Pages updated.
>
>> > MathMLToDisplay/Presentation/TokenElements/ms/ms1.html
>> > MathMLToDisplay/Presentation/TokenElements/ms/msAdisplaystyle2.html
>> > MathMLToDisplay/Presentation/TokenElements/ms/msAtoken4.html
>> > MathMLToDisplay/Presentation/TokenElements/ms/msAtoken5.html
>> > MathMLToDisplay/Presentation/TokenElements/ms/msScolorscope6.html
>> > MathMLToDisplay/Presentation/TokenElements/ms/msSinheritance7.html
>> > The reference file should use mathvariant="monospace" rather than
>> style="font-family:monospace" since the browser's monospace font is
>> not the same as the math monospace font. Several tests produced math
>> processing errors, which I have fixed. The font size problem for
>> absolute font sizes still needs to be fixed.
>
> I think I have the font size problem taken care of.
>
>> Using mathvariant="monospace" seems to fail in HTML-CSS output.
>
> OK, I have fixed that. The handling of the font was different in SVG
> and HTML-CSS, and I've made them both be the same.
>
Yes, I think the font size problem is fixed. I've done the change for
mathvariant="monospace". It seems that they are remaining small
differences. For example, I see that the opening and closing quotes
behave differently with respect to the style applied. I'll have to run
the tests again to see what they are precisely.
Frédéric WANG
>
>
>> > Configuration/Hub/menuSettings/zoom-1.html (three instances)
>> > The event-handling code has been completely rewritten, and there is
>> no longer a Mousemove function in the MathZoom code. You might be
>> able to replace that with the new Hover() method (I haven't tried it).
>>
>> Just replacing MouseOver by Hover seems to work. All zoom tests pass
>> with Opera. The last one, zoomConfig=Hover&zoomTrigger=Hover fails on
>> Firefox but it was already marked "fails" before.
>
> OK, I'll look at FF for this, but don't think it is crucial for now.
test work for the SVG output. In the latest results from yesterday
http://devel.mathjax.org/testing/web/results/v2.0-candidate/2012-02-06/Linux_Firefox_default_STIX-SVG-latest.html.gz
http://devel.mathjax.org/testing/web/results/v2.0-candidate/2012-02-06/Windows_Chrome_default_STIX-SVG.html.gz
http://devel.mathjax.org/testing/web/results/v2.0-candidate/2012-02-06/Windows_Chrome_default_STIX.html.gz
All zoom tests look good now. So I'll remove the fails-if(Firefox) marker.
>
>> > MathMLToDisplay/Presentation/TokenElements/mglyph/rec-mglyph1.html
>> > I don't think the test is correct. MathJax doesn't produce mtext
>> elements for missing characters, for one thing. I also wonder if you
>> have "Curlz MT" on the test machine (that test passes for me, because
>> I do have it).
>>
>> The idea is to test various mglyph with fonts that may or may not
>> exit on the machine (my-braid-font is really unlikely to be installed
>> while Arial is likely to be). It verifies the presence of the
>> character if the glyph is found or of the alttext when it is not
>> found. Note that this test uses getElementByClassName to find the
>> HTML span's with class "mglyph" and "mtext" produced by MathJax. This
>> is a bit fragile, it was broken and I fixed it but I'm open to a
>> better solution to find the character/alttext.
>
> OK, I guess I didn't look closely enough to see that it would work
> with HTML-CSS. The SVG jax can be told to retain the MathML structure
> in a similar way, so it could probably be made to work there as well.
>
Yes, I can certainly adapt the test for SVG later. But I think the SVG
output behaves differently, it does not use the alttext and always
generates a character. So I'll see that after the MathJax 2.0 release.
Frédéric WANG
On 06/02/2012 21:33, Davide P. Cervone wrote:
Thanks. I've fixed some issues with SVG output in
MathMLToDisplay/Presentation/GeneralLayout/mpadded/mpadded-6a.htmlMathMLToDisplay/Presentation/TablesAndMatrices/mtable/align-1.htmlMathMLToDisplay/Presentation/TablesAndMatrices/mtable/align-3a.htmlMathMLToDisplay/Presentation/TablesAndMatrices/mtable/align-3b.htmland an issue that was causing problems with Opera and some of the table tests. I don't remember if I already mentioned that or not.
http://devel.mathjax.org/testing/web/results/v2.0-candidate/2012-02-06/Linux_Opera_default_TeX-SVG.html.gz
but I may not have taken your latest changes when I ran it. I think I have not answered to some of your other reports about recent fixes. I'll run the test again to verify them. I'll also remove the "fails" marker on the tests written to verify issues from the tracker, so we will better see the failures. I believe there are remaining ones including a couple of tests that I have to fix/update.
Davide P. Cervone
>>> > MathMLToDisplay/Presentation/TokenElements/ms/
>>> > MathMLToDisplay/Presentation/TokenElements/ms/msAtoken4.html
>>> > MathMLToDisplay/Presentation/TokenElements/ms/msAtoken5.html
>>> > MathMLToDisplay/Presentation/TokenElements/ms/msScolorscope6.html
>>> > MathMLToDisplay/Presentation/TokenElements/ms/msSinheritance7.html
>>> > The reference file should use mathvariant="monospace" rather
>>> than style="font-family:monospace" since the browser's monospace
>>> font is not the same as the math monospace font. Several tests
>>> produced math processing errors, which I have fixed. The font
>>> size problem for absolute font sizes still needs to be fixed.
>>
>> I think I have the font size problem taken care of.
>>
>>> Using mathvariant="monospace" seems to fail in HTML-CSS output.
>>
>> OK, I have fixed that. The handling of the font was different in
>> SVG and HTML-CSS, and I've made them both be the same.
>>
> Yes, I think the font size problem is fixed. I've done the change
> for mathvariant="monospace". It seems that they are remaining small
> differences. For example, I see that the opening and closing quotes
> behave differently with respect to the style applied. I'll have to
> run the tests again to see what they are precisely.
I've checked it, and it is a bug in MathJax's handling of the font
attributes. I'll look into it.
Davide
Davide P. Cervone
>>> > The event-handling code has been completely rewritten, and there
>>> is no longer a Mousemove function in the MathZoom code. You might
>>> be able to replace that with the new Hover() method (I haven't
>>> tried it).
>>>
>>> Just replacing MouseOver by Hover seems to work. All zoom tests
>>> pass with Opera. The last one, zoomConfig=Hover&zoomTrigger=Hover
>>> fails on Firefox but it was already marked "fails" before.
>>
>> OK, I'll look at FF for this, but don't think it is crucial for now.
> Apparently I looked to the Firefox result for SVG, before I made the
> test work for the SVG output. In the latest results from yesterday
>
> http://devel.mathjax.org/testing/web/results/v2.0-candidate/2012-02-06/Linux_Firefox_default_STIX-SVG-latest.html.gz
> http://devel.mathjax.org/testing/web/results/v2.0-candidate/2012-02-06/Windows_Chrome_default_STIX-SVG.html.gz
> http://devel.mathjax.org/testing/web/results/v2.0-candidate/2012-02-06/Windows_Chrome_default_STIX.html.gz
>
> All zoom tests look good now. So I'll remove the fails-if(Firefox)
> marker.
Great!
>>> > MathMLToDisplay/Presentation/TokenElements/mglyph/rec-mglyph1.html
>>> > I don't think the test is correct. MathJax doesn't produce
>>> mtext elements for missing characters, for one thing. I also
>>> wonder if you have "Curlz MT" on the test machine (that test
>>> passes for me, because I do have it).
>>>
>>> The idea is to test various mglyph with fonts that may or may not
>>> exit on the machine (my-braid-font is really unlikely to be
>>> installed while Arial is likely to be). It verifies the presence
>>> of the character if the glyph is found or of the alttext when it
>>> is not found. Note that this test uses getElementByClassName to
>>> find the HTML span's with class "mglyph" and "mtext" produced by
>>> MathJax. This is a bit fragile, it was broken and I fixed it but
>>> I'm open to a better solution to find the character/alttext.
>>
>> OK, I guess I didn't look closely enough to see that it would work
>> with HTML-CSS. The SVG jax can be told to retain the MathML
>> structure in a similar way, so it could probably be made to work
>> there as well.
>
> Yes, I can certainly adapt the test for SVG later. But I think the
> SVG output behaves differently, it does not use the alttext and
> always generates a character. So I'll see that after the MathJax 2.0
> release.
Yes, the SVG output jax does not have the machinery to test fonts and
characters within them, so it just assumes everything is OK. More can
be done with this in the future.
Davide
Davide P. Cervone
On 06/02/2012 21:33, Davide P. Cervone wrote:These do not seem to be fixed in the output from yesterdayThanks. I've fixed some issues with SVG output in
MathMLToDisplay/Presentation/GeneralLayout/mpadded/mpadded-6a.htmlMathMLToDisplay/Presentation/TablesAndMatrices/mtable/align-1.htmlMathMLToDisplay/Presentation/TablesAndMatrices/mtable/align-3a.htmlMathMLToDisplay/Presentation/TablesAndMatrices/mtable/align-3b.htmland an issue that was causing problems with Opera and some of the table tests. I don't remember if I already mentioned that or not.
http://devel.mathjax.org/testing/web/results/v2.0-candidate/2012-02-06/Linux_Opera_default_TeX-SVG.html.gz
but I may not have taken your latest changes when I ran it.
I'll also remove the "fails" marker on the tests written to verify issues from the tracker, so we will better see the failures. I believe there are remaining ones including a couple of tests that I have to fix/update.
Frédéric WANG
> Right, those where changes I made yesterday in response to the output
> that you site. But I think they should work now.
New results for Opera/Firefox will appear here in a moment:
http://devel.mathjax.org/testing/web/results/v2.0-candidate/2012-02-07/
(but I have not used your two last commits)
Frédéric WANG
translating some <math> elements. Here are the remaining issues (just
FYI since I don't think they are important for v2.0):
MathMLToDisplay/Presentation/GeneralLayout/mpadded/mpadded/mozilla/mpadded-4.html
lspace can not be used as a pseudo unit, but seems to have an effect in
MathJax I already reported it once. I just sent a report to GitHub, so
we won't lose it.
MathMLToDisplay/Presentation/GeneralLayout/mpadded/mpadded-2a.html
MathMLToDisplay/Presentation/GeneralLayout/mpadded/mpadded-2b.html
You already gave me suggestions long time ago to modify these tests, I
still have to work on this. (I think they work when I used the XHTML
doctype)
MathMLToDisplay/Presentation/GeneralLayout/mpadded/mpadded-6b.html
This test is marked "random". The size of the rectangles do not match
exactly. I think you said it was a rounding issues during length
computation.
Frédéric WANG
OK, I verified it on Firefox and they seem to be fixed. (at the naked eyes)
MathMLToDisplay/Presentation/GeneralLayout/mpadded/mpadded-6a.htmlMathMLToDisplay/Presentation/TablesAndMatrices/mtable/align-1.htmlMathMLToDisplay/Presentation/TablesAndMatrices/mtable/align-3a.htmlMathMLToDisplay/Presentation/TablesAndMatrices/mtable/align-3b.html
Frédéric WANG
MathMLToDisplay/Presentation/GeneralLayout/mpadded/mpadded-6a.htmlMathMLToDisplay/Presentation/TablesAndMatrices/mtable/align-1.htmlMathMLToDisplay/Presentation/TablesAndMatrices/mtable/align-3a.htmlMathMLToDisplay/Presentation/TablesAndMatrices/mtable/align-3b.html
Frédéric WANG
Linux_Firefox_default_STIX-SVG
MathMLToDisplay/Topics/StretchyChars/horizontal-braces-2.htmlNot sure what is causing the thickening of the lines, or the slight space difference. BUt not sure it really matters.
This test was supposed to be used for STIX fonts only, but SVG do not use them as you just told me, so we can ignore this failure.
Davide P. Cervone
Davide P. Cervone
Frédéric WANG
I think I fixed a problem with Opera in many of the table tests where the colored boxes weren't covering the table properly. (A work-around to an Opera display bug caused bad side-effects.)
Davide
MathMLToDisplay/Presentation/TablesAndMatrices/mtable/align-1.html
Frédéric WANG
>> > Configuration/Hub/menuSettings/zoom-1.html
>> > Configuration/Hub/menuSettings/zscale-1.html
>>
>> => OK, I modified these tests to take into account the SVG ouput case.
>> I think zscale-1.html passes for me with the SVG output but not the
>> HTML-CSS output.
>
> It looks OK in HTML-CSS to me (by eye). Can you say what is going
> wrong for you?
>
is visible by eye). Maybe it depends on the system configuration. I
think you told me it works for you on Mac. I have not had the occasion
to access the Mac test machine since the last time, so I don't know.
See the zscale-1 diff in the results:
http://devel.mathjax.org/testing/web/results/v2.0-candidate/2012-02-07/Linux_Firefox_default_STIX.html.gz
http://devel.mathjax.org/testing/web/results/v2.0-candidate/2012-02-07/Linux_Firefox_default_TeX.html.gz
http://devel.mathjax.org/testing/web/results/v2.0-candidate/2012-02-07/Linux_Opera_default_TeX.html.gz
>
>> > MathMLToDisplay/General/GenAttribs/href1.html
>> > MathMLToDisplay/General/GenAttribs/href2.html
>> > MathMLToDisplay/General/GenAttribs/href3.html
>> > MathMLToDisplay/General/GenAttribs/link-1.html
>> > MathMLToDisplay/General/GenAttribs/link-2.html
>> > MathMLToDisplay/Presentation/TokenElements/mglyph/mglyph3.html
>> >
>> MathMLToDisplay/Presentation/TokenElements/mglyph/mglyph_aspect_gif.html
>> > MathMLToDisplay/Presentation/TokenElements/mglyph/mglyph_aspect.html
>> >
>> MathMLToDisplay/Presentation/TokenElements/mglyph/mglyph_stretched.html
>> >
>> MathMLToDisplay/Presentation/TokenElements/mglyph/mglyph_valignbottom.html
>> >
>> MathMLToDisplay/Presentation/TokenElements/mglyph/mglyph_valignmiddle.html
>> >
>> MathMLToDisplay/Presentation/TokenElements/mglyph/mglyph_valigntop.html
>>
>> => Should I mark these tests "fails" in SVG output mode?
>
> Yes, I think so. I'm not planning to do the background image support
> any time soon in SVG.
>
I'm going to do so.
>
>> >
>> MathMLToDisplay/Presentation/TablesAndMatrices/mtable/rowlines-3-2.html
>> > The antialiasing on the single line versus the overprinted line are
>> different (because the partial pixels add up to darker values)
>>
>> => Disabling antiliasing for lines make them disappear. So I'll have
>> to come with another idea for this test...
>
I'll mark this fails-if(SVG) too.
Davide P. Cervone
Davide P. Cervone
>>> > Configuration/Hub/menuSettings/zscale-1.html
>>>
>>> => OK, I modified these tests to take into account the SVG ouput
>>> case.
>>> I think zscale-1.html passes for me with the SVG output but not
>>> the HTML-CSS output.
>>
>> It looks OK in HTML-CSS to me (by eye). Can you say what is going
>> wrong for you?
>>
> The font size in the seems slightly different in the zoom boxes
> (but it is visible by eye). Maybe it depends on the system
> configuration. I think you told me it works for you on Mac. I have
> not had the occasion to access the Mac test machine since the last
> time, so I don't know.
>
> See the zscale-1 diff in the results:
>
> http://devel.mathjax.org/testing/web/results/v2.0-candidate/2012-02-07/Linux_Firefox_default_STIX.html.gz
> http://devel.mathjax.org/testing/web/results/v2.0-candidate/2012-02-07/Linux_Firefox_default_TeX.html.gz
> http://devel.mathjax.org/testing/web/results/v2.0-candidate/2012-02-07/Linux_Opera_default_TeX.html.gz
OK, I'll check into it.
Davide
Frédéric WANG
> Actually, I think it was mtable-1-1a.ref and a bunch of the higher
> numbered ones.
>
> Davide
All the MathMLToDisplay/Presentation/TablesAndMatrices/mtable/mtable-*
are green
Davide P. Cervone
> numbered ones.
>>
>> Davide
>
> OK, that seems to be fixed according to this morning's results:
>
> http://devel.mathjax.org/testing/web/results/v2.0-candidate/2012-02-07/Linux_Opera_default_TeX-SVG.html.gz
>
> All the MathMLToDisplay/Presentation/TablesAndMatrices/mtable/mtable-
> * are green
Great! Thanks!
Davide P. Cervone
OK, I think I've been able to fix most of the mpadded tests, by translating some <math> elements. Here are the remaining issues (just FYI since I don't think they are important for v2.0):
MathMLToDisplay/Presentation/GeneralLayout/mpadded/mpadded/mozilla/mpadded-4.html
lspace can not be used as a pseudo unit, but seems to have an effect in MathJax I already reported it once. I just sent a report to GitHub, so we won't lose it.
MathMLToDisplay/Presentation/GeneralLayout/mpadded/mpadded-6b.html
This test is marked "random". The size of the rectangles do not match exactly. I think you said it was a rounding issues during length computation.
Frédéric WANG
> MathJax doesn't reject values with bad units, it just ignores the
> units. So it sees "3lspace" as just "3". That should be a multiplier
> of the default value, but I wasn't passing that into the measurement
> routine, and that made it default to 3ems. I have fixed the problem.
>
OK, but the default value for lspace is 0 so that should make the test pass.
>> MathMLToDisplay/Presentation/GeneralLayout/mpadded/mpadded-6b.html
>>
>> This test is marked "random". The size of the rectangles do not match
>> exactly. I think you said it was a rounding issues during length
>> computation.
>
> I looked more closely, and it is the fact that background colors are
> made slightly larger than their contents in order to properly cover
> slight differences in the antialiasing of characters (which causes
> them to fall slightly outside the font metric bounding boxes). I will
> keep it on file to fix in the future, but don't think it is worth it
> for now.
>
Yes, I agree.
Davide P. Cervone
>> units. So it sees "3lspace" as just "3". That should be a
>> multiplier of the default value, but I wasn't passing that into the
>> measurement routine, and that made it default to 3ems. I have
>> fixed the problem.
>
> OK, but the default value for lspace is 0 so that should make the
> test pass.
Yes, but as I said, the routine didn't have the default value. Now it
does.
Davide
Frédéric WANG
Davide P. Cervone
over the last week. There are a couple small things left that I need
to fit, but other than that, I am satisfied with the test results.
Davide
On Feb 7, 2012, at 3:01 PM, Frédéric WANG wrote:
> New results:
>
> http://devel.mathjax.org/testing/web/results/v2.0-candidate/2012-02-07/latest/
>
Davide P. Cervone
Davide P. Cervone
Configuration/HTML-CSS/undefinedFamily-1.html needs to be fixed for
two reasons: first, the TeX fonts now remap the letter-like symbols
to the locations where they are found in the fonts, so the U+2147 is
no in the TeX fonts. Second, this character is NOT in STIXNonUnicode
(and there are no characters in common between STIXNonUnicode and
STIXGeneral). I would recommend changing to U+222F in STIXIntegralsD
and STIXGeneral instead.
Davide
Davide P. Cervone
Davide P. Cervone
Davide P. Cervone
In MathMLToDisplay/Presentation/GeneralLayout/mpadded/mpadded1.html
there is sometimes a vertical shift in the "C". This is because when
the C and | are in the same math element, they share a common
baseline, but in the separated version, inside separate div's, they
don't. To fix that, you could add
<mphantom><mtext>|</mtext></mphantom>
to get
<div style="position: absolute; left: 0; top: 0; z-index: 0;">
<math xmlns="http://www.w3.org/1998/Math/MathML">
<mi> C </mi> <mphantom><mtext>|</mtext></mphantom>
</math>
</div>
in the reference file. That will make sure the C has the same
baseline as the | in both cases. (You might add the phantom C to the
| to make sure that way also is correct, but it hasn't been needed so
far.)
Davide
Frédéric WANG
Here are a couple of things I noticed while looking through some of the results:
MathMLToDisplay/Presentation/CSS/mprescripts/mprescripts-04.htmlThere seem to be wrong characters in the reference (circles rather than diamonds), or perhaps it is the test that should have circles?
MathMLToDisplay/Presentation/CSS/mtable/mtable-09.htmlMathMLToDisplay/Presentation/CSS/mtable/mtable-10.htmlMathMLToDisplay/Presentation/CSS/mtable/mtable-11.htmlMathMLToDisplay/Presentation/CSS/mtable/mtable-12.htmlMathMLToDisplay/Presentation/CSS/mtable/mtable-13.htmlMathMLToDisplay/Presentation/CSS/mtable/mtable-14.htmlMathMLToDisplay/Presentation/CSS/mtable/mtable-15.htmlMathMLToDisplay/Presentation/CSS/mtable/mtable-16.htmlLooks like code is missing from the reference file. (They all start with </mtd> as the first thing in the <math> tag)
"
MathMLToDisplay/Presentation/CSS/mfenced-04MathMLToDisplay/Presentation/CSS/mfenced-05MathMLToDisplay/Presentation/CSS/mfenced-06MathMLToDisplay/Presentation/CSS/mprescripts/*MathMLToDisplay/Presentation/CSS/mtable/*
The author of these tests says "Right hand side of equation
should look like mirrored copy of left hand side". To convert
these tests into reftests, the experimental CSS "transform"
property has been used. However, the tests and references do not
seem to match exactly."
UI/math-menu/math-menu-1.htmlLooks like MathEvents.js needs to be added to the extensions array.
Thanks.
Frédéric WANG
> These look great. I'm very pleased with how much we have accomplished
> over the last week. There are a couple small things left that I need
> to fit, but other than that, I am satisfied with the test results.
>
> Davide
Thank you for your feedback, Davide. I'll try to do the changes you
suggested and run the tests again this week when I have time.
Yes, I think the results look fine on Firefox & Opera, but I think we
should at least execute the tests on Chrome, Firefox, Internet Explorer
(various document modes), Opera and Safari. I have not been able to
access Design Science test machine, so I've used my own machine (Linux).
I have Windows 7 installed as a virtual machine, but it is very slow to
run tests (I'll see if I can borrow another computer with Windows). I
don't think I can find a Mac, though.
Davide P. Cervone
> suggested and run the tests again this week when I have time.
I know that you have used up your time for this week, but do hope that
we can finish things up next week.
> Yes, I think the results look fine on Firefox & Opera, but I think
> we should at least execute the tests on Chrome, Firefox, Internet
> Explorer (various document modes), Opera and Safari. I have not been
> able to access Design Science test machine, so I've used my own
> machine (Linux). I have Windows 7 installed as a virtual machine,
> but it is very slow to run tests (I'll see if I can borrow another
> computer with Windows). I don't think I can find a Mac, though.
I agree, and think we do need to see IE and Chrome tests yet (Safari
if possible).
If I were to run the tests, would I need to install things on my own
machine, or does it get run through a website somewhere? I have never
looked into how the system works (though I know you have told me about
it in the past).
Davide
Davide P. Cervone
Davide P. Cervone
Davide P. Cervone
Frédéric WANG
Here are a couple of things I noticed while looking through some of the results:
MathMLToDisplay/Presentation/CSS/mprescripts/mprescripts-04.htmlThere seem to be wrong characters in the reference (circles rather than diamonds), or perhaps it is the test that should have circles?
MathMLToDisplay/Presentation/CSS/mtable/mtable-09.htmlMathMLToDisplay/Presentation/CSS/mtable/mtable-10.htmlMathMLToDisplay/Presentation/CSS/mtable/mtable-11.htmlMathMLToDisplay/Presentation/CSS/mtable/mtable-12.htmlMathMLToDisplay/Presentation/CSS/mtable/mtable-13.htmlMathMLToDisplay/Presentation/CSS/mtable/mtable-14.htmlMathMLToDisplay/Presentation/CSS/mtable/mtable-15.htmlMathMLToDisplay/Presentation/CSS/mtable/mtable-16.htmlLooks like code is missing from the reference file. (They all start with </mtd> as the first thing in the <math> tag)
UI/math-menu/math-menu-1.htmlLooks like MathEvents.js needs to be added to the extensions array.
Frédéric WANG
Since I force TeX fonts in this page, I mark the test "require(TeX)".
Frédéric WANG
Frédéric WANG
I think according to the REC mathvariant is "stronger" than other style or MathML2 attributes. For example
<mtext mathvariant="fraktur" style="font-weight:bold">
<mtext mathvariant="fraktur">
Not sure it is really important, though.
Davide P. Cervone
Frédéric WANG
> If I were to run the tests, would I need to install things on my own
> machine, or does it get run through a website somewhere? I have never
> looked into how the system works (though I know you have told me about
> it in the past).
>
thing and one or more test machines with only browsers + a Selenium
server. So in theory, one could just use the central component (which is
installed on webfaction) to send instructions to his own machine (that
was my initial goal).
Unfortunately, I have only been able to make the communication work in a
local network so far, so you actually need to install the central
component on a machine which is connected to the same local network (of
course, that can be your own machine). This later configuration (central
component + browsers + Selenium server) is already done on the machine
that Design Science makes available to the MathJax project, but you have
to connect to it remotely and that does not seem to work very well at
the moment.
Anyway, I think it is worth trying to install the testing framework on
your machine at some point. When you want to do so, have a look to:
http://devel.mathjax.org/testing/web/docs/html/installation.html
and tell me when you are stuck (all the info is not available in the
doc, but I already made the configuration for the Mac, so I should be
able to help you). You can start without installing the Web interface
since the framework can also be controlled with the command line:
http://devel.mathjax.org/testing/web/docs/html/qa-command-line.html
Frédéric WANG
Frédéric WANG
http://devel.mathjax.org/testing/web/results/v2.0-candidate/2012-02-08/
Davide P. Cervone
following:
MathMLToDisplay/Presentation/TokenElements/mn/mnSscriptlevel11.html
MathMLToDisplay/Presentation/TokenElements/ms/msAdisplaystyle2.html
MathMLToDisplay/Presentation/TokenElements/ms/msAtoken4.html
MathMLToDisplay/Presentation/TokenElements/ms/msAtoken5.html
MathMLToDisplay/Presentation/TokenElements/ms/msSinheritance8.html
MathMLToDisplay/Presentation/TokenElements/mtext/mtextAtoken3.html
(It was converting font-weight:normal to font-weight:400 and that
confused MathJax.)
Davide
Frédéric WANG
I have fixed the problem with
MathMLToDisplay/Presentation/GeneralLayout/mpadded/mozilla/mpadded-5.html
in Opera.
MathMLToDisplay/Presentation/GeneralLayout/mpadded/mpadded-6a.html
Davide P. Cervone
I believe I have resolved the issue with
MathMLToDisplay/General/GenAttribs/style2.html
in Opera. (Opera converted font-weight:bold to font-weight:700, so I had to add extra logic to convert that back.)
Davide
Yes, it is green in the latest results.
I have found the problem that caused the parens to stretch unnecessarily in
MathMLToDisplay/Presentation/TokenElements/mo/mo2.htmlMathMLToDisplay/Presentation/TokenElements/mo/mo6.html
and have fixed it.
These tests pass to in the latest results.
I have fixed the problem with
MathMLToDisplay/Presentation/GeneralLayout/mpadded/mozilla/mpadded-5.html
in Opera.
The test fails in the latest results. However, the screenshot taken yesterday shows large difference of coordinates of the squares. Now, I only see a small size difference. That looks like the case of
MathMLToDisplay/Presentation/GeneralLayout/mpadded/mpadded-6a.html
Frédéric WANG
publish them here in 30-45min:
http://devel.mathjax.org/testing/web/results/v2.0-candidate/2012-02-08/
Davide P. Cervone
Davide P. Cervone
OK, I'll run the tests again for Opera, using your last commit. I'll publish them here in 30-45min:
http://devel.mathjax.org/testing/web/results/v2.0-candidate/2012-02-08/
Frédéric WANG
Can you please tell me which configs HTML-CSS and SVG have or not in common? Here is where I use the gConfigObject["HTML-CSS"] and may need to add gConfigObject["SVG"] or to skip the test in SVG mode:
fred@debian:~/mathjax-project/MathJax-test$ find testsuite/ -name *.html | xargs grep -A4 'gConfigObject\["HTML\-CSS"\]'
testsuite/MathMLToDisplay/Presentation/CSS/mspace/mspace-02.html: gConfigObject["HTML-CSS"].linebreaks = { automatic: true };
testsuite/MathMLToDisplay/Presentation/CSS/mspace/mspace-02.html- gConfigObject["SVG"] = { linebreaks: { automatic: true } };
testsuite/MathMLToDisplay/Presentation/CSS/mspace/mspace-02.html- }
testsuite/MathMLToDisplay/Presentation/CSS/mspace/mspace-02.html- </script>
testsuite/MathMLToDisplay/Presentation/CSS/mspace/mspace-02.html- </head>
--
testsuite/MathMLToDisplay/Presentation/GeneralLayout/maction/tooltip-1-ref.html: gConfigObject["HTML-CSS"].tooltip = { delayPost: 0 };
testsuite/MathMLToDisplay/Presentation/GeneralLayout/maction/tooltip-1-ref.html- }
testsuite/MathMLToDisplay/Presentation/GeneralLayout/maction/tooltip-1-ref.html- </script>
testsuite/MathMLToDisplay/Presentation/GeneralLayout/maction/tooltip-1-ref.html-
testsuite/MathMLToDisplay/Presentation/GeneralLayout/maction/tooltip-1-ref.html- </head>
--
testsuite/MathMLToDisplay/Presentation/GeneralLayout/maction/tooltip-2b.html: gConfigObject["HTML-CSS"].tooltip = { delayPost: 0 };
testsuite/MathMLToDisplay/Presentation/GeneralLayout/maction/tooltip-2b.html- window.scrollTo(0, document.getElementById("id").offsetTop);
testsuite/MathMLToDisplay/Presentation/GeneralLayout/maction/tooltip-2b.html- }
testsuite/MathMLToDisplay/Presentation/GeneralLayout/maction/tooltip-2b.html-
testsuite/MathMLToDisplay/Presentation/GeneralLayout/maction/tooltip-2b.html- function postMathJax()
--
testsuite/MathMLToDisplay/Presentation/GeneralLayout/maction/tooltip-2-ref.html: gConfigObject["HTML-CSS"].tooltip = { delayPost: 0 };
testsuite/MathMLToDisplay/Presentation/GeneralLayout/maction/tooltip-2-ref.html- window.scrollTo(0, document.getElementById("id").offsetTop);
testsuite/MathMLToDisplay/Presentation/GeneralLayout/maction/tooltip-2-ref.html- }
testsuite/MathMLToDisplay/Presentation/GeneralLayout/maction/tooltip-2-ref.html- </script>
testsuite/MathMLToDisplay/Presentation/GeneralLayout/maction/tooltip-2-ref.html-
--
testsuite/MathMLToDisplay/Presentation/GeneralLayout/maction/tooltip-2a.html: gConfigObject["HTML-CSS"].tooltip = { delayPost: 0 };
testsuite/MathMLToDisplay/Presentation/GeneralLayout/maction/tooltip-2a.html- window.scrollTo(0, document.getElementById("id").offsetTop);
testsuite/MathMLToDisplay/Presentation/GeneralLayout/maction/tooltip-2a.html- }
testsuite/MathMLToDisplay/Presentation/GeneralLayout/maction/tooltip-2a.html-
testsuite/MathMLToDisplay/Presentation/GeneralLayout/maction/tooltip-2a.html- function postMathJax()
--
testsuite/MathMLToDisplay/Presentation/GeneralLayout/maction/tooltip-1.html: gConfigObject["HTML-CSS"].tooltip = { delayPost: 0 };
testsuite/MathMLToDisplay/Presentation/GeneralLayout/maction/tooltip-1.html- }
testsuite/MathMLToDisplay/Presentation/GeneralLayout/maction/tooltip-1.html-
testsuite/MathMLToDisplay/Presentation/GeneralLayout/maction/tooltip-1.html- function postMathJax()
testsuite/MathMLToDisplay/Presentation/GeneralLayout/maction/tooltip-1.html- {
--
testsuite/Configuration/HTML-CSS/mtextFontInherit/sans-serif.html: gConfigObject["HTML-CSS"].mtextFontInherit = true;
testsuite/Configuration/HTML-CSS/mtextFontInherit/sans-serif.html- gConfigObject["SVG"] = {mtextFontInherit: true};
testsuite/Configuration/HTML-CSS/mtextFontInherit/sans-serif.html- }
testsuite/Configuration/HTML-CSS/mtextFontInherit/sans-serif.html- </script>
testsuite/Configuration/HTML-CSS/mtextFontInherit/sans-serif.html- </head>
--
testsuite/Configuration/HTML-CSS/mtextFontInherit/fantasy.html: gConfigObject["HTML-CSS"].mtextFontInherit = true;
testsuite/Configuration/HTML-CSS/mtextFontInherit/fantasy.html- gConfigObject["SVG"] = {mtextFontInherit: true};
testsuite/Configuration/HTML-CSS/mtextFontInherit/fantasy.html- }
testsuite/Configuration/HTML-CSS/mtextFontInherit/fantasy.html- </script>
testsuite/Configuration/HTML-CSS/mtextFontInherit/fantasy.html- </head>
--
testsuite/Configuration/HTML-CSS/mtextFontInherit/cursive.html: gConfigObject["HTML-CSS"].mtextFontInherit = true;
testsuite/Configuration/HTML-CSS/mtextFontInherit/cursive.html- gConfigObject["SVG"] = {mtextFontInherit: true};
testsuite/Configuration/HTML-CSS/mtextFontInherit/cursive.html- }
testsuite/Configuration/HTML-CSS/mtextFontInherit/cursive.html- </script>
testsuite/Configuration/HTML-CSS/mtextFontInherit/cursive.html- </head>
--
testsuite/Configuration/HTML-CSS/mtextFontInherit/serif.html: gConfigObject["HTML-CSS"].mtextFontInherit = true;
testsuite/Configuration/HTML-CSS/mtextFontInherit/serif.html- gConfigObject["SVG"] = {mtextFontInherit: true};
testsuite/Configuration/HTML-CSS/mtextFontInherit/serif.html- }
testsuite/Configuration/HTML-CSS/mtextFontInherit/serif.html- </script>
testsuite/Configuration/HTML-CSS/mtextFontInherit/serif.html- </head>
--
testsuite/Configuration/HTML-CSS/mtextFontInherit/monospace.html: gConfigObject["HTML-CSS"].mtextFontInherit = true;
testsuite/Configuration/HTML-CSS/mtextFontInherit/monospace.html- gConfigObject["SVG"] = {mtextFontInherit: true};
testsuite/Configuration/HTML-CSS/mtextFontInherit/monospace.html- }
testsuite/Configuration/HTML-CSS/mtextFontInherit/monospace.html- </script>
testsuite/Configuration/HTML-CSS/mtextFontInherit/monospace.html- </head>
--
testsuite/Configuration/HTML-CSS/tooltip-1-ref.html: gConfigObject["HTML-CSS"].tooltip = { delayPost: 0, delayClear: 5000,
testsuite/Configuration/HTML-CSS/tooltip-1-ref.html- offsetX: 0, offsetY: 0 };
testsuite/Configuration/HTML-CSS/tooltip-1-ref.html- }
testsuite/Configuration/HTML-CSS/tooltip-1-ref.html-
testsuite/Configuration/HTML-CSS/tooltip-1-ref.html- function tooltipOver()
--
testsuite/Configuration/HTML-CSS/scale-1.html: gConfigObject["HTML-CSS"].scale = 200;
testsuite/Configuration/HTML-CSS/scale-1.html- }
testsuite/Configuration/HTML-CSS/scale-1.html- </script>
testsuite/Configuration/HTML-CSS/scale-1.html- <script type="text/javascript" src="../../header.js"></script>
testsuite/Configuration/HTML-CSS/scale-1.html- </head>
--
testsuite/Configuration/HTML-CSS/undefinedFamily-1-ref.html: gConfigObject["HTML-CSS"].undefinedFamily = "STIXGeneral";
testsuite/Configuration/HTML-CSS/undefinedFamily-1-ref.html- }
testsuite/Configuration/HTML-CSS/undefinedFamily-1-ref.html- </script>
testsuite/Configuration/HTML-CSS/undefinedFamily-1-ref.html- <script type="text/javascript" src="../../header.js"></script>
testsuite/Configuration/HTML-CSS/undefinedFamily-1-ref.html- </head>
--
testsuite/Configuration/HTML-CSS/tooltip-1.html: gConfigObject["HTML-CSS"].tooltip = {
testsuite/Configuration/HTML-CSS/tooltip-1.html- delayPost: delayPost,
testsuite/Configuration/HTML-CSS/tooltip-1.html- delayClear: delayClear,
testsuite/Configuration/HTML-CSS/tooltip-1.html- offsetX: offsetX,
testsuite/Configuration/HTML-CSS/tooltip-1.html- offsetY: offsetY
--
testsuite/Configuration/HTML-CSS/minScaleAdjust-1.html: gConfigObject["HTML-CSS"].minScaleAdjust = 300;
testsuite/Configuration/HTML-CSS/minScaleAdjust-1.html- }
testsuite/Configuration/HTML-CSS/minScaleAdjust-1.html- </script>
testsuite/Configuration/HTML-CSS/minScaleAdjust-1.html- <script type="text/javascript" src="../../header.js"></script>
testsuite/Configuration/HTML-CSS/minScaleAdjust-1.html- </head>
--
testsuite/Configuration/HTML-CSS/undefinedFamily-1.html: gConfigObject["HTML-CSS"].undefinedFamily = "STIXIntegralsD";
testsuite/Configuration/HTML-CSS/undefinedFamily-1.html- }
testsuite/Configuration/HTML-CSS/undefinedFamily-1.html- </script>
testsuite/Configuration/HTML-CSS/undefinedFamily-1.html- <script type="text/javascript" src="../../header.js"></script>
testsuite/Configuration/HTML-CSS/undefinedFamily-1.html- </head>
--
testsuite/Crashtests/issue170.html: gConfigObject["HTML-CSS"] = {
testsuite/Crashtests/issue170.html- availableFonts: null,
testsuite/Crashtests/issue170.html- preferredFont: null,
testsuite/Crashtests/issue170.html- webFont: "TeX"
testsuite/Crashtests/issue170.html- }
Frédéric WANG
Davide P. Cervone
Can you please tell me which configs HTML-CSS and SVG have or not in common?
Here is where I use the gConfigObject["HTML-CSS"] and may need to add gConfigObject["SVG"] or to skip the test in SVG mode:
testsuite/MathMLToDisplay/Presentation/CSS/mspace/mspace-02.html: gConfigObject["HTML-CSS"].linebreaks = { automatic: true };
testsuite/MathMLToDisplay/Presentation/CSS/mspace/mspace-02.html- gConfigObject["SVG"] = { linebreaks: { automatic: true } };
testsuite/MathMLToDisplay/Presentation/GeneralLayout/maction/tooltip-1-ref.html: gConfigObject["HTML-CSS"].tooltip = { delayPost: 0 };
testsuite/MathMLToDisplay/Presentation/GeneralLayout/maction/tooltip-2b.html: gConfigObject["HTML-CSS"].tooltip = { delayPost: 0 };
testsuite/MathMLToDisplay/Presentation/GeneralLayout/maction/tooltip-2-ref.html: gConfigObject["HTML-CSS"].tooltip = { delayPost: 0 };
testsuite/MathMLToDisplay/Presentation/GeneralLayout/maction/tooltip-2a.html: gConfigObject["HTML-CSS"].tooltip = { delayPost: 0 };
testsuite/MathMLToDisplay/Presentation/GeneralLayout/maction/tooltip-1.html: gConfigObject["HTML-CSS"].tooltip = { delayPost: 0 };
testsuite/Configuration/HTML-CSS/mtextFontInherit/sans-serif.html: gConfigObject["HTML-CSS"].mtextFontInherit = true;
testsuite/Configuration/HTML-CSS/mtextFontInherit/sans-serif.html- gConfigObject["SVG"] = {mtextFontInherit: true};
testsuite/Configuration/HTML-CSS/mtextFontInherit/fantasy.html: gConfigObject["HTML-CSS"].mtextFontInherit = true;
testsuite/Configuration/HTML-CSS/mtextFontInherit/fantasy.html- gConfigObject["SVG"] = {mtextFontInherit: true};
testsuite/Configuration/HTML-CSS/mtextFontInherit/cursive.html: gConfigObject["HTML-CSS"].mtextFontInherit = true;
testsuite/Configuration/HTML-CSS/mtextFontInherit/cursive.html- gConfigObject["SVG"] = {mtextFontInherit: true};
testsuite/Configuration/HTML-CSS/mtextFontInherit/serif.html: gConfigObject["HTML-CSS"].mtextFontInherit = true;
testsuite/Configuration/HTML-CSS/mtextFontInherit/serif.html- gConfigObject["SVG"] = {mtextFontInherit: true};
testsuite/Configuration/HTML-CSS/mtextFontInherit/monospace.html: gConfigObject["HTML-CSS"].mtextFontInherit = true;
testsuite/Configuration/HTML-CSS/mtextFontInherit/monospace.html- gConfigObject["SVG"] = {mtextFontInherit: true};
testsuite/Configuration/HTML-CSS/tooltip-1-ref.html: gConfigObject["HTML-CSS"].tooltip = { delayPost: 0, delayClear: 5000,
testsuite/Configuration/HTML-CSS/tooltip-1-ref.html- offsetX: 0, offsetY: 0 };
testsuite/Configuration/HTML-CSS/scale-1.html: gConfigObject["HTML-CSS"].scale = 200;
testsuite/Configuration/HTML-CSS/undefinedFamily-1-ref.html: gConfigObject["HTML-CSS"].undefinedFamily = "STIXGeneral";
testsuite/Configuration/HTML-CSS/tooltip-1.html: gConfigObject["HTML-CSS"].tooltip = {
testsuite/Configuration/HTML-CSS/tooltip-1.html- delayPost: delayPost,
testsuite/Configuration/HTML-CSS/tooltip-1.html- delayClear: delayClear,
testsuite/Configuration/HTML-CSS/tooltip-1.html- offsetX: offsetX,
testsuite/Configuration/HTML-CSS/tooltip-1.html- offsetY: offsetY
testsuite/Configuration/HTML-CSS/minScaleAdjust-1.html: gConfigObject["HTML-CSS"].minScaleAdjust = 300;
testsuite/Configuration/HTML-CSS/undefinedFamily-1.html: gConfigObject["HTML-CSS"].undefinedFamily = "STIXIntegralsD";
testsuite/Crashtests/issue170.html: gConfigObject["HTML-CSS"] = {
testsuite/Crashtests/issue170.html- availableFonts: null,
testsuite/Crashtests/issue170.html- preferredFont: null,
testsuite/Crashtests/issue170.html- webFont: "TeX"
testsuite/Crashtests/issue170.html- }
Davide P. Cervone
OK, that works. Thank you!
Frédéric WANG
>> Can you please tell me which configs HTML-CSS and SVG have or not in
>> common?
I think I'll have to write more tests for the new SVG configuration
options (anyway, when MathJax v2.0 is published, I'll read the new doc
and add tests for new features) and maybe make a separate directory
Configuration/SVG.
Davide P. Cervone
>>> in common?
>
> OK, I have made the required changes.
> I think I'll have to write more tests for the new SVG configuration
> options (anyway, when MathJax v2.0 is published, I'll read the new
> doc and add tests for new features) and maybe make a separate
> directory Configuration/SVG.
OK, makes sense. I'll be working on documentation next week. Thanks
again for all your help and efforts.
Davide
Frédéric WANG
http://devel.mathjax.org/testing/web/results/v2.0-candidate/2012-02-09/
Frédéric WANG
Frédéric WANG
Quirks mode:
In SVG mode, I have an error in MathJax.js line 972, character 11. Not
sure that it is related, since the test execution stops on these pages
in HTML-CSS too and I think I also found the error for other pages.
Frédéric WANG
> In SVG mode, I have an error in MathJax.js line 972, character 11. Not
> sure that it is related, since the test execution stops on these pages
> in HTML-CSS too and I think I also found the error for other pages.
>
Another page where the test execution stopped:
Frédéric WANG
http://devel.mathjax.org/testing/web/results/v2.0-candidate/2012-02-13/
Frédéric WANG
New results Opera/Firefox:
http://devel.mathjax.org/testing/web/results/v2.0-candidate/2012-02-09/
Configuration/Contexts/svg-1a.html
Configuration/Contexts/svg-1a.html
the problem is not in the way screenshots are taken as I previously suggested but in the lack of support for foreignObject. As you said in the user list, it does not work in Opera and Internet Explorer. So I'll mark these tests fails-if(Opera||MSIE).
Frédéric WANG
Processing Error]. I found one test that has this error in SVG output
Jax (in Firefox too):
Davide P. Cervone
Frédéric WANG
Frédéric WANG
version):
Davide P. Cervone
in doing the background color in mtd elements.
Davide
Davide P. Cervone
stretching routine from the wrong place. Good calls for these two.
Davide
On Feb 14, 2012, at 9:03 AM, Frédéric WANG wrote:
Frédéric WANG
> I have fixed the problem in my v2.0-candidate branch. There was a bug
> in doing the background color in mtd elements.
>
> Davide
I've started the test for Opera again with your latest commits.
I've fixed several test pages so I hope the results will be better.
Davide P. Cervone
the problems. I have a fix for the problem that only was occurring
for the packed copy, but haven't committed yet. You are too fast for
me!
Davide
Frédéric WANG
I thought they were pretty good, but I'm glad that we are ironing out the problems. I have a fix for the problem that only was occurring for the packed copy, but haven't committed yet. You are too fast for me!
Davide
http://devel.mathjax.org/testing/web/results/v2.0-candidate/2012-02-14/
So with the fix for API/OOP/super-3.html, all API tests should now pass in Opera!
Davide P. Cervone
Davide