The MathML Acid3 test essentially relies on the classical Acid3 and just modifies the Javascript tests in order to verify some MathML features. Thus the requirement to pass the MathML Acid3 is the same:
To pass the test, a browser must use its default settings, the animation has to be smooth, the score has to end on 100/100, and the final page has to look exactly, pixel for pixel, like this reference rendering
The strategy
of the MathML Acid3 test is to let the browser layout MathML expressions
and to determine positions and sizes of elements via the
getBoundingClientRect
Javascript function. This does not allow to
test features like colors or links, but these are already verified in the
MathML Acid2 test. In general, the MathML specification gives some freedom and
so the corresponding tests are not too strict: for example one test just
verifies that in an <mfrac> element, the numerator is above a
denumerator, not precise coordinates or sizes.
Sometimes, a more accurate measurement is necessary. For that purpose,
the MathML Acid3 test uses a special Acid3MathML family that is
made available as Web fonts. These fonts contain characters used in the tests:
ASCII letters, mathematical alphanumeric Symbols (to test
mathvariant
) and some operators from the MathML Operator
Dictionary. Their sizes are given by the table below. Test 0 verifies that
these Web fonts are downloaded and retry several times if necessary.
Style | Width | Height | |
---|---|---|---|
bold-italic | 256 | 1024 | 1/4 |
sans-serif-bold-italic | 384 | 1024 | 3/8 |
bold | 512 | 1024 | 1/2 |
bold script | 576 | 1024 | 9/16 |
bold-fraktur | 640 | 1024 | 5/8 |
sans-serif-bold | 704 | 1024 | 11/16 |
italic | 768 | 1024 | 3/4 |
sans-serif-italic | 832 | 1024 | 13/16 |
monospace | 896 | 1024 | 7/8 |
normal | 1024 | 1024 | 1 |
script | 1088 | 1024 | 17/16 |
fraktur | 1152 | 1024 | 9/8 |
sans-serif | 1216 | 1024 | 19/16 |
double-struck | 1280 | 1024 | 5/4 |
However, this is still not enough to get perfect measure and results might
depend on some screen resolution, default font size, whether the page is zoom
in/out, whether automatic screen resizing is used on some mobile platforms etc
The MathML Acid3 test uses only relative em
measures. In test 0,
a value is determined for the current
font size of the page, which may vary according to zoom level or automatic
screen resizing. Next, the following approximate comparison functions are
used:
where .
Hence
means that modulo a small error.
This error is "absolute" once the is fixed.
is "relative" in the sense that the tolerance grows with the magnitude of
.
As a rule of thumb,
is used to compare coordinates
(the tolerance should not depend on these coordinates)
while
is used to compare
sizes or distances (the tolerance is larger for big or far away objects).
Of course, we assume that
is nonzero (e.g. the objects have nonzero sizes) and even at least
baseSize
.
Rationale for the : if
are objects of size
then
and this is equivalent to
for the base size.
The value compared to is inspired from
the
approximation
errors but we accomodate the fact that the document base size
may vary (absolute case) or that we can not distinguish between the exact and
approximative values (relative case).
For convenience the following approximate equality functions are
also defined:
Sometimes we want to tolerate even more errors
(e.g. tests to verify support for stretchy operators, which are not
always stretched perfectly by the classical TeX method) or want to
be sure that two values are really distinct (e.g. the bottom coordinate of
a base and exponent in msup
). The MathML Acid3 test uses a
parameter for that purpose
which should be understood as a fraction of some size (e.g. the base size).
Finally, the MathML tests are contained in a div of width 1000em and this is assumed to be large enough so that automatic line breaking does not happen by default. Of course, tests for line breaking use narrower containers.
This is a very simple test to start with:
<math>
is tested and should be
http://www.w3.org/1998/Math/MathML
.
display="block"
)
breaks (bottom of X is at most as low as top of Y):
These are tests for <mrow>
, <msub>
,
<msup>
, <msubsup>
,
<mover>
, <munder>
and <munderover>
(left to right):
Test 1 verifies some sizes:
<mrow>
is less than the heights of the elements that have scripts
attached to the BASE. The height of elements with one script is less
than the height of the corresponding element with two scripts.
<msub>
,
<msup>
, <msubsup>
),
the width of these elements should be larger than the one of the
<mrow>
.<mover>
, <munder>
and <munderover>
) the width of these elements should
be the same as the width of the <mrow>
.
Test 2: verifies some positions:
<msub>
and
<msubsup>
should be lower than the base.
This is verified by testing that the top of the subscripts are lower
than the top of the base. Similarly, the test
checks that the supscripts of
<msup>
and <msubsup>
are higher than
the base.<msub>
,
<msup>
, <msubsup>
should be placed on the right of the base. The test verifies that
the right coordinate of the base is at most the left coordinate of the
scripts.
<mover>
, <munder>
and <munderover>
should be placed between the left and
right coordinates of the base. The test verifies that the
left coordinate of base is at most the left coordinate of the scripts and
similarly for the right coordinates.
<mover>
, <munder>
and <munderover>
should be placed above/below the base. The test verifies that
the top of the base is at most as low as the bottom of the overscripts.
Similarly for the underscripts.A simple test for the <mfrac>
element, where
numerator and denumerator have the same size.
This test verifies some properties of the <msqrt>
element:
<msqrt>
) is
nonzero.
This test verifies the following properties of the <mroot>
element:
This is a simple test to verify the support for the box and circle notations
of menclose. The test contains some nested <menclose>
elements: an <mtext>
element,
framed with an <menclose>
"box",
circled by a <menclose>
"circle",
framed, and finally circled again.
We assume here that the notations are drawn with
rectangle and ellipse whose axis are the horizontal/vertical axis of the text
and
that the notations do not overlap. Hence the width and height of an
<menclose>
"box" should be at least those its content. Simple math shows that the width and
height of the <menclose>
"circle" should be at least
times as large as its content.
With the previous nesting, the outermost <menclose>
is
times as large as the inner <mtext>
. Hence
the test verifies the following properties:
<mtext>
should be inside the <menclose>
.
This is verified by comparing the
top, bottom, left and right coordinates.<menclose>
should be at least twice as
large as the child. This is verified by comparing the width.
This test verifies a couple of equivalence for menclose constructions:
<msqrt>
element.The test only verifies that the size of equivalent constructions are equal.
This is a bit lax and thus a rendering engine that does not implement
<menclose>
at all might actually pass the test. Hence an additional
verification is done to exclude this case:
the width of an <msqrt>
element should not be equal to
the width of its content.
This test contains a <semantics>
element with an <mtext>
child annotated
by <annotation>
and <annotation-xml>
elements of encoding "application/x-tex"
and "application/xhtml+xml"
.
It is assumed that a MathML rendering engine
will just display the annotated <mtext>
and hide the others. Hence the
test verifies that the <semantics>
size is the same as
the <mtext>
child.
This is similar to test 8, except that <maction>
elements are used with
actiontype tooltip, statusline and toggle. In the two first cases, only the
first element must be visible. In the last case, the selection attribute is
used to display only the second element. As in test 8, we compare the size
of the expected visible child with the size of the maction element.
This test contains a trivial verification about the mrow, mstyle and mphantom elements. Basically, they should have the same size as their content:
__
__
__
These are combined with a somewhat
less easy verification so that the whole test
won't pass in browsers without MathML support. Basically we check that
an msub with three <mtext>
children generates an invalid markup message but
not when the two first are grouped into an <mrow>
element.
Again, we verify the
difference by width comparison. We assume that the width of the text in
the error message is negligible compared to the width of the
<mtext>
element.
For that purpose, the actual test contains long
<mtext>
string, rather than
just one "X" as below.
These are basic tests on an <mtable>
of 3 rows and 3
columns. Test 11 verifies metrics of <mtr>
elements:
Test 12 verifies metrics of mtd elements:
This test contains an <mmultiscripts>
element with
4 prescripts and 4 postscripts. The prescript at the top and right
as well as the postscript at the bottom right are
<none>
elements. All
the other scripts have the same size. The test verifies that:
This test contains two spaces of em dimensions (width, height, depth) given by (5, 3, 2) and (15, 4, 6). The test verifies that
This test contains four <mpadded>
elements of em
dimensions
(width, height, depth) given by (5, 3, 2), (15, 4, 6), (10, 20, 10) and
(3, 1.5, 1). The fourth is included in the third, with em shift
(lspace, voffset) given by (2, 2.5). The test verifies that:
This test contains the following token elements: <mtext>X</mtext>, <ms lquote="XXX" rquote="XX">X</ms>, <mi>X</mi>, <mi>XX</mi> and <mn>X</mn>. The test verifies that:
<mtext>
(three X's for rquote
,
one inner X and two X's for the lquote
).ms
and <mtext>
are the
same.mi
is twice the one of the <mtext>
(an mi
with several characters is not slanted)mi
is
the one of the <mtext>
(an
mi
with one character is italic, the ratio is from the
table about Acid3MathML fonts)
A first test contains an mfrac element with linethickness="2em". It verifies that the total mfrac height is at least the sum of the height of the numerator, denumerator and linethickness and that the bottom of the numerator and the top of the denumerator are separated by at least the linethickness.
An mfrac element with numerator and denumerator of different sizes is aligned with numalign="left" (respectively an denomalign="right"). The widest child is the denumerator (respectively numerator) so that the test is nontrivial. The test verifies the alignement with respect to the mfrac element.
Finally, an mfrac with bevelled="true" is tested. In that case, the right of the numerator is at most the left of the denumerator and the top of the numerator is higher than the top of the denumerator.
This test verifies the subscriptshift/superscriptshift attributes for the msub, msup and msubsup elements. The base is a square of size 4em and the shift is 6em. Hence the test verifies that the vertical gap between the base and the script is at least 2em.
This test verifies the align attribute of the munder/mover/munderover, that is whether the base and scripts are aligned with respect to their left, center or right. Additionally, the base is checked to be at most three times larger than the scripts, so that the test is nontrivial.
This test verifies the effect of the accent and accentunder attributes. Here, the test verifies that an accent script is drawn closer to the base than a normal script. See also test 33 for the size comparison. A small verification is done to check that the distance between the base and script is nonzero.
This test verifies the alignement of mtable with respect to the baseline when the align attribute is (from left to right) top, bottom, the bottom of the second row and the top of the penultimate row.
This test verifies the effect of rowalign/columnalign
on
mtable
, mtr
and mtd
elements. We have a table of 2 rows and 2 columns whose alignment
value on cells is (from left to right and top to bottom):
rowalign=bottom, columnalign=left ;
rowalign=bottom, columnalign=right,
rowalign=top, columnalign=left ; and rowalign=top, columnalign=right. The
cells contain spaces of different sizes and thus a small test ensures that
those spaces have nonzero sizes.
This test contains a with two columns whose width is set by the columnwidth attribute to "1em" and "2em".
This test contains a table with a single cell. The width attribute is used to set the width of the table to "5em".
This test contains two almost identical mtable elements with four rows and four columns. Their (rowspacing, columnspacing) attributes are set to ("1em 1.5em 2em", "1.5em 2.5em 3em") and ("3em 4.5em 2em", "3.5em 5.5em 7em") respectively. The test verifies that height of the first table minus the height of the second table is the difference of the sum of rowspacing values. Similarly for the width and columnspacing values.
This test contains a mlabeledtr element with a LABEL and an EQUATION. The
parent mtable
contains a
side="right"
attribute so the LABEL should be
displayed on the right of the EQUATION.
This test contains a mlabeledtr element with a LABEL and an EQUATION. The minlabelspacing on the parent table is "2em" so the test verifies that the distance between the LABEL and the EQUATION is at most that wide.
As in test 25, we have two almost identical tables and compare the difference of size between the two tables. The tables have different framespacing values and the difference should match the difference of height/width of the two tables.
As in test 22, this is a table of four cells of different sizes and a small test verifies that the mspace element used is indeed supported. The table has equalrow and equalcolumns set to true and so the actual test measures that this is the case.
This test contains a table with two cells that have rowspan="2" and columnspan="2" respectively. The test verifies that these cells have same height/width as the adjacents cells.
This is just a fragment of text with mathsize="2em" and thus the test verifies that its size is as expected twice as large as the base size.
This test contains some text with different mathvariant values. The widths are measured and verified to match the values indicated in the table about Acid3MathML fonts:
Note that it should render exactly the same as if the corresponding Unicode code points were used instead of mathvariant:
This is the same as test 20, but we verify that an accent script is larger than a normal script, because the scriptlevel is not incremented.
This test contains mover/munder elements with movablelimits="true". The first has displaystyle="true" and so the script should be above the base while the second has displaystyle="false" and so the script should be next to the base. The test verifies positions as in test 2.
This contains two tests. The first one is an mfrac with mathsize="10em" with scriptsizemultiplier=".5" and since the scriptlevel is increased by one in the numerator/denumerator, the size becomes "5em". We assume that the scriptminsize is not reached.
The second is an mfrac in displaystyle="true". Using the technique of test 34 with movablelimits, we verify that the displaystyle is reset in the numerator/denumerator: the munder/mover elements should have their scripts on the right.
This is similar to test 35 for mroot. We verify that displaystyle is reset within the mroot index and that scriptlevel is increased by 2
This is similar to test 35 for msub. We verify that displaystyle is reset within the msup script and that scriptlevel is increased by 1.
This is similar to test 35 for munder. We verify that displaystyle is reset within the munder script and that scriptlevel is increased by 1.
This is similar to test 38 with an accent script. In that case, the scriptlevel should not increase.
This test contains three summation symbols. One in displaystyle="true" and (and largeop="true" per the operator dictionary). A second one in displaystyle="true" but largeop="false". And a third one with displaystyle="false". The first should be larger than the others and the two last symbols should have the same size.
This test contains a text with mathsize="8em" and scriptsizemultiplier=".5". A scriptlevel="2" attribute is used to force the scriptlevel and thus the final size should be 2em.
This is similar to test 41: the initial size is 32em, the scriptsizemultiplier is .5 and the scriptlevel is set to 5. In theory, the size should become 1em. However, the scriptminsize is set to 8em, so this should be the value used instead.
This is a simple "X" operator with lspace="3.5em" and rspace="4em". Hence the total distance between the previous and next element should be 10.5em
This contains two parenthesis next to space of total height 6em. The first has stretchy="false" and should not stretch while the second has stretchy="true" and should stretch.
This is similar to test 44, but the space has height 9em and depth 1em. Instead of largeop, we test symmetric. When it is true, the parenthesis symmetrically (height=18em) otherwise it should not (height=10em).
Again we have an mspace element of total height 20em and check the height of an adjacent stretchy operator. maxsize is set to "10em" so the operator should stretch, but at most to that size.
This is similar to test 46, but with an mspace element of total height 2em and an operator with minsize="10em". Hence the operator should stretch to that size.
This test contains two minus operators with form attribute set to infix and prefix respectively. Per the operator dictionary, the (rspace, lspace) values should be (mediummathspace, mediummathspace) and (0, veryverythinmathspace) respectively. We perform a verification similar to the one of test 43.
;
This test is similar to test 48, except that we let the rendering engine determines the default value of the form attribute. The four rules given in the MathML specification are verified.
This test contains various embellished operators near an mspace element of size 20em. Hence the operator at the core should stretch to that size.
This test contains various mrow elements with an operator and a space-like element. Hence these mrow elements are embellished operators and we use a verification similar to the one of test 50.
This test contains
an msqrt element with tall mspace elements and stretchy operators inside.
The test verifies vertical stretching inside the implicit mrow child of
the <msqrt>
element.
This test vertical stretching in mtd elements. The cells have vertical stretchy operators or tall mspace elements and the operators should stretch to the size of the largest mspace element in the same row.
This is similar to tests 54 and 45. Basically, we verify that the rule for symmetric stetching applies when rowalign is "baseline" but not when it is "bottom".
In this test, a vertical stretchy operator is contained inside a cell with rowspan="2". The second column is a cell of rowspan="3" and is ignored. So the stretchy operator should stretch to cover the height of the two first cells in the third column.
This test verifies stretching of horizontal arrows inside an munder/mover/munderover element.
This is the counterpart of test 53 for horizontal stretching.
This is the counterpart of test 55 for horizontal stretching.
This is similar to previous tests, but combines columnspan, rowspan, vertical stretching and horizontal stretching.
This is similar to tests 50 and 51 but combined in a more complex way. The horizontal arrow and vertical bar should stretch.
This is similar to test 40, but using the default largeop value from the operator dictionary.
This is similar to test 44. The test verifies the stretchiness of various horizontal operators from the operator dictionary
This is similar to test 44. The test verifies the stretchiness of various vertical operators from the operator dictionary
This is similar to test 43. This test verifies the spacing around various operators from the operator dictionary for a given form.
This test verifies that various mrow-like elements are layout from right to left when dir="rtl" is used. The test compares the coordinates of the "X" and "Y" children and the "Y" should be on the left of the "X".
This is the counterpart of test 2 in RTL mode. The only difference should be that the scripts of the msub/msup/msubsup elements are now on the left of the base.
This is similar to test 17 but in RTL mode. The behavior of the numalign/denomalign attributes should not change but a bevelled fraction should be drawn from right to left.
This is the counterpart of test 13 in RTL mode. The only difference is that scripts are now positioned from right to left.
This is a test for mpadded in RTL mode. Basically, we only check that lspace="5em" is the space between the X and Y.
This is the counterpart of test 4 in RTL mode. The square root symbol should now be on the right.
This is the counterpart of test 5 in RTL mode. The index is now placed on the right of the base.
This is the counterpart of tests 11, 12 in RTL mode. The cells in a row should be layout from right to left.
This test contains a formula given by an mtext of width 6em, an operator of width 1em and an mtext of width 6em. The operator is a plus and so has linebreakstyle=before in the operator dictionary. The width of the parent div is 10.5em, so the formula should break before the operator. The test done is similar to the one in test 0.
This is similar to test 73, but the operator is a comma and so has linebreakstyle=after. Hence the formula should break after the operator.
This is similar to test 73, but the mtext elements have only width of 1em and so no break should happen. However, the operator has linebreak="newline" and so the formula should break before the operator.
This test contains an <mtext>
of width 6em, a plus operator of width 2em,
an <mtext>
of width 8em, a comma operator of width 2em and
an <mtext>
of width 8em. The width of the parent div is
20.5em.
In theory, the
formula may break after the comma but since this one has linebreak="nobreak",
the formula should break before the plus.
This is similar to test 76, except that the plus has
linebreak="goodbreak"
and the comma has
linebreak="badbreak"
. Hence the formula should break before
the plus.
This test contains an mtext of width 6em, a plus of width 2em and an mtext of width 6em. The parent div has width 8.5em and so the formula should break before the plus. Moreover, the operator has lineleading="5em", so the space between the bottom of the first mtext and the top of the plus should be 5em.
This is similar to test 73 but the mo element has indentalign="right" instead. Hence the indent before the plus should at least be 2em.
This is similar to test 79, but with indentshift="2em" instead. Again, the indent before the plus should at least be 2em.
This table contains two rows, each one with one cell. The first cell is "ABC" with malignmark edge="right" at the end and the second cell is "DEF" with malignmark edge="left". The two marks should be aligned, like this:
ABC| |DEF
This is similar to test 81, the first cell has maligngroup groupalign="right" and the second maligngroup groupalign="left" so the table should again render like this:
ABC| |DEF
Here, the first cell is "ABCDEF" with groupalign="center" and the second has "1234" with malignmark on the middle, so the table should render like
ABC|DEF 12|34
Here, the first align group is "ABC.EF" with groupalign=decimalpoint and the second is "1234" with malignmark edge="left" on the middle and another malignmark (this one should be ignored). The table should render like this:
ABC|.FG 12|34
This is similar to test 81 but with several groupalign elements and malignmark at different places. The table should render like this:
|ABCD A|BCD AB|CD ABC|D ABCD|
This is similar to test 82 but with several maligngroup elements in each cell. The groupalign attribute is used on the mtd elements to specify the alignment. The table should render like this:
|[ABC][E|F] [GHIJ]| [01]| |[234] [56]|[78]
This is similar to test 86, but the groupalign attribute is specified on the first mtr element.
This is similar to test 86, but the groupalign attribute is specified on the mtable element.
This is a simple test for the mstack and msrow elements that should render like this:
424 + 33
The test verifies that the bottom of "424" is at most the top of the "+", that the "+" and "33" are horizontally aligned and that the left (respectively right) of "424" is vertically aligned with the "+" (respectively "33").
This is a simple test for the mstack and msline elements, that should render like this:
123 --- 456
The test verifies that the bottom first line is at most as low as the top of the last line and that their left/right coordinates are aligned.
This is a simple test for the msgroup element and shift attribute, that should render like this:
123 456 456 789
The test verifies that the two first lines are aligned and that the two last lines are aligned. The two last lines should be shifted to the left with respect to the two first lines.
This is a simple test for the leftoverhang, rightoverhang and mslinethickness attributes of the msline element, that should render like this:
012 =======
The test measures the extra amount that the line overhangs on the right of the 012 (rightoverhang="5em"), the extra amount that the line overhangs on the left of the 012 (leftoverhang="2.5em") and the linethickness of the line (mslinethickness="3em")
This is a simple test for the mstack@stackalign attribute, that should render like this:
1 111 1 111 1 111
The test verifies that a line with a "111" is indeed wider than a line with a "1" (to avoid making the test trivial) and that the pairs of lines are aligned left, center and right.
This test verifies that the mscarries element increments scriptlevel by 1 and change the default value of scriptsizemultiplier to 0.6em. The initial size is set to 10em so the size inside mscarry should be 6em.
This is a simple test for mlongdiv, that should render like this:
16 ------ 64) 1024 0000
The test verifies that "64" is on the right of "16" and "1024", that 16 is above "1024" and that "64" and "1024" are aligned. It verifies that "1024" and "0000" have same width, are aligned and that "1024" is above "0000".
This is similar to test 95, but with a couple of alternative notations:
stackedrightright left/\right stackedleftleft 1024 | 64 64 / 1024 \ 16 64 | 1024 |----- -----| | 16 16 |
This test verifies compatibility of MathML with Javascript. Initially, we have an empty mstyle element:
<math> <mstyle id="test97"> </mstyle> </math>
Then, the test performs the following operations:
textContent
of the mo to "|"At that step, you get the following structure:
<mrow> <mo>|</mo> <mi></mi> <mtext></mtext> </mrow>
Then the test performs the following operations:
At that step, you get the following structure:
<mpadded height="0" depth="0"> <mspace depth="4em" height="4em"/> </mpadded>
Then the test performs the following operations:
At that step, you get the following structure:
<math> <mstyle id="test97"> <mrow> <mo>|</mo> <mtext></mtext> </mrow> <mpadded> <mspace depth="4em" height="4em"/> </mpadded> </mstyle> </math>
Finally, the mrow becomes an embellished operator. The height of the mpadded is the height of the mspace, that is 8em. Hence the test verifies that the mo bar stretches to that size.
This test verifies compatibility of MathML with SVG and HTML. A MathML
root is inserted inside an SVG image, rotated by 180°. The MathML element
contains an mover element, an <mtext>
with embedded SVG and a semantics with
embedded HTML. The test checks:
Another test verifies the compatibility of MathML line breaking with the CSS one. An inline formula is placed inside a table cell. This HTML table is itself contained in a div of width 5em. Hence this will also be the cell width and thus the one used by the MathML line breaking algorithm. The formula contains an mtext "ABC" (3em), a plus mo (1em) and an mtext "DEF" (3em) and so should break. The test checks that the bottom of "ABC" is at most as low as the top of "DEF".
This test verifies compatibility of MathML with CSS using basic rules that modify the font-size:
math.test99 :first-child { font-size: 2em; }
style="font-size: 3em"
attribute.
#test99 > mn { font-size: 4em; }
Note that is really a pure CSS test (albeit nodes are MathML) and so should even pass in browsers without MathML support.