![[Graphics:presentationgr1.gif]](presentationgr1.gif)
should be considered an infix
operator.
This document describes the XML elements proposed as the "presentation language" for the core MathML.
Presentation elements correspond to the constructors of traditional math notation. They are intended to be medium-independent, in the sense that there are sensible ways to render them in audio, as well as in the traditional visual medium for math. Since traditional notation is mainly visual, the descriptions of which notational constructs the elements represent, and how they are typically rendered, is often given in visual terms. Some attributes may make sense only for visual media, although renderers for other media are encouraged to treat all attributes in some analogous way if possible.
Note that HTML in general specifies the logical structure of data, but only suggests (does not require) specific renderings for data, in order to allow for medium-independence and also for individual preferences of rendering, as well as to ease automatic processing of data; MathML presentation elements are fully compatible with this philosophy.
The presentation elements are meant to express the syntactic structure of math notation in much the same way as titles, sections, and paragraphs capture the higher level syntactic structure of a textual document. Because of this, for example, a single row of identifiers and operators may be enclosed by nested <MROW> schema, and bases of superscripts are not just the rightmost character, but the full base. This structure allows for better quality renderings of math, especially when details of the rendering environment such as display widths are not known by the document author.
Certain extended characters (represented by entity references) are used to name operators or identifiers which in traditional notation render the same as other entities, such as "ⅆ" or "ⅈ", or invisibly, such as "⁢", "⁡", "&MissingTerm;", or "⁣". These are distinct notational entities, as evidenced by their distinct spoken renderings and in some cases by their effects on linebreaking and spacing in visual rendering, and as such should be represented by the appropriate specific entities.
The complete list of MathML entities is given in Section 6.
The presentation elements are divided into two classes, "tokens" which have only #PCDATA as content, and "layout schema" which have only elements as content. There are also a few empty elements used only in conjunction with certain layout schema.
All tokens (in the syntactic sense) in a mathematical expression should be enclosed by MathML token tags. The primary MathML token types are identifiers (variables, function names, ...), numbers, operators, fences (e.g. a parenthesis), and string literal. There are also token elements for representing text or whitespace which has no mathematical meaning.
The layout schema are the constructors of expressions in traditional math notation.
Each MathML presentation element is described below in detail. The valid attributes, along with their default values, are listed for each element. Examples are interspersed with the element and attribute descriptions.
According to the XML draft, attributes given to elements must have the form:
attr = "..."where space around the '=' is optional. The attribute value must be quoted.
Attribute values specified as number are allowed to be integers or floating-point numbers (i.e. digits with one decimal point), optionally preceded by a minus sign. For some attributes, only those in a subset of the expressible values are sensible, but values outside this subset are not errors, but rather are rounded up or down (at the discretion of the renderer) to the closest value in that direction within the allowed subset.
Attribute values that depend upon the font are given in font-related units. For example, the spacing around an operator such as "+" is given in "em"s. Using font-related units allows the expressions to grow or shrink proportionately to the current font size.
Another technical detail involves whitespace between begin/end tags. By default, XML processors remove all leading and trailing whitespace (blanks, tabs, and newlines) between the begin/end tags and collapse any internal white space to a single space (" ") character. MathML uses this default behavior. Authors wishing to encode blanks, tabs, or newlines at the start or end of the content of a token, or in sequences of more than one, must use entity references for these characters.
Many of the elements described herein require a specific number of arguments (always 1, 2, or 3). In the detailed discussions of element syntax given below, the number of required arguments is implicitly indicated by giving names for the arguments at various positions. A few elements have additional requirements on the number or type of arguments, which are described with the individual element. All elements which allow an arbitrary sequence of arguments (e.g. <MROW>) allow that sequence to be empty. The preceding rules are intended to make the allowed numbers of arguments unambiguous for every element described herein.
MathML also contains a generic separator element, <SEP/>, which is ignored in all presentation elements; unlike all other elements, it is not counted in determining the number or position of arguments for elements for which this matters.
The only empty token element is <MSPACE/>. The empty
elements which can only occur inside certain layout schema are
described with those layout schema; these elements are:
<MPRESCRIPTS/>
<NONE/>
The <SEP/> empty element (generic to MathML) is ignored where ever it appears in presentation elements. It can appear only in layout schema, never in token elements, according to the XML DTD, since token elements contain only #PCDATA.
Certain elements are considered "space-like": <MTEXT>, <MSPACE/>, and <MPHANTOM>. This affects some of the rules for typical rendering behavior noted in various sections below.
Certain elements (e.g., <MOVER>) are able to embellish operators which are their first argument. The definition of "embellished operator" affects the rules for stretching of operators. These elements are listed in the section on <MO> and <MF>.
The element <MF> behaves almost exactly like <MO>, and both should be considered "operators" from the point of view of the rules for rendering embellished or stretchy operators, described in the section on <MO> and <MF>.
| <MI> | identifier |
| <MN> | number |
| <MO> | operator |
| <MF> | fence |
| <MTEXT> | text |
| <MSPACE/> | space |
| <MS> | string literal |
| <MSTYLE> | style change |
| <MERROR> | encloses a syntax error message from a preprocessor |
| <MPHANTOM> | makes contents invisible but preserves their size |
| <MROW> | horizontally groups any number of subexpressions |
| <MFRAC> | forms a fraction from two subexpressions |
| <MSQRT> | forms a square root sign (radical without an index) |
| <MROOT> | forms a radical with specified index |
| <MSUB> | attach a subscript to a base |
| <MSUP> | attach a superscript to a base |
| <MSUBSUP> | attach a sub- superscript pair to a base |
| <MUNDER> | attach an underscript to a base |
| <MOVER> | attach an overscript to a base |
| <MUNDEROVER> | attach an under- overscript pair to a base |
| <MMULTISCRIPTS> | attaches tensor-style indices to a base |
| <MTABLE> | table or matrix |
| <MTR> | row in a table or matrix |
| <MTD> | one entry in a table or matrix |
All tokens allow any sequence of 0 or more characters (or extended characters represented as entity references) as their content. In particular, tokens with no content are allowed. The allowed set of entity names for extended characters is given in Section 6.
Every character or entity reference allowed as content in the presentation elements of MathML must occur as part of the content of a token element.
Identifiers include variables, function names, and symbolic constants. No extra spacing is added around identifiers by typical graphical renderers.
| Name | values | default | |
| fontsize | number (points) | inherited | |
| fontweight | plain | bold | inherited | |
| fontslant | plain | italic | automatic | |
| fontfamily | string | inherited | |
| fontcolor | #rrggbb | inherited |
Most attribute values are inherited from the surrounding context. The surrounding context of a math element should be given by the browser to the program which is the implementor of the math element. The exception to the inheritance default is the font slant. Single character identifiers are typically drawn (by default) in an "italic" font; multiple character identifiers are drawn in a plain (non-slanted) font.
Future extensions should allow for other values for the font weight and font slant in keeping with whatever standard emerges for giving font attributes in HTML.
<MI>x</MI>
<MI>π</MI>
<MI>D</MI>
<MI>sin</MI>
Identifiers include functions names such as "sin". Expressions such as "sin x" are written using the ⁡ (⁡ as a short name) operator as shown below. ⁡ typically renders as whitespace.
<MROW>
<MI>sin</MI>
<MO>⁡</MO>
<MI>x</MI>
</MROW>
Miscellaneous text that should be treated as a "term" can also be represented by an <MI> element, as in:
<MROW>
<MN>1</MN>
<MO>+</MO>
<MI>...</MI>
<MO>+</MO>
<MI>n</MI>
</MROW>
Any token that is numeric. No extra spacing is added around numbers by typical graphical renderers. Unlike the case of <MI>, all <MN> tokens are typically rendered in an unslanted font.
Same as for <MI>.
<MN>2</MN>
<MN>0.123</MN>
<MN>1,000,000</MN>
<MN>2.1e10</MN>
Any token that is an operator. These include infix, prefix, and postfix operators. (Fences, i.e. bracketing tokens such as braces, parentheses, and "absolute-value" bars, are represented with <MF>.)
The attributes for <MO> are same as those for <MI> together with:
| Name | values | default | |
| lspace | number (ems) | set by dictionary (.2777777) | |
| rspace | number (ems) | set by dictionary (.2777777) | |
| stretchy | true | false | set by dictionary (false) | |
| symmetric | true | false | set by dictionary (true) | |
| maxsize | number | infinity | set by dictionary (infinity) | |
| minsize | number | set by dictionary (0) | |
| largeop | true | false | set by dictionary (false) | |
| movablelimits | true | false | set by dictionaty (false) | |
| form | prefix | infix | postfix | set by dictionary (rule given below) |
The maxsize and minsize are given as multipliers of the font size.
See rendering rules common to operators and fences below for a discussion on the attributes.
<MO>+</MO>
<MO>≤</MO>
<MO>++</MO>
<MO>∑</MO>
<MO>.NOT.</MO>
Any token that is a fence, i.e. a member of a matched pair of bracketing tokens such as braces, parentheses, and "absolute-value" bars. Matched pairs of fences should be given as the first and last elements of an <MROW> whose single middle element represents the expression enclosed by the fences.
The attributes for fences are same as for operators, except for movablelimits and largeop.
The form attribute for <MF> can have the values "open" or "close" for left and right fences respectively. The appropriate default value of this attribute is specified in the operator / fence dictionary for common fences.
See rendering rules common to operators and fences below for further discussion on the attributes.
Some examples of expressions involving fences:
(a+b)
<MROW>
<MF>(</MF>
<MROW>
<MI>a</MI>
<MO>+</MO>
<MI>b</MI>
</MROW>
<MF>)</MF>
</MROW>
[0,1)
<MROW>
<MF>[</MF>
<MROW>
<MN>0</MN>
<MO>,</MO>
<MN>1</MN>
</MROW>
<MF>)</MF>
</MROW>
Typical visual rendering behaviors for operators and fences are essentially identical, and are more complex than for other tokens, so the rules for both are described in this separate section. Note that, like all rendering rules in MathML, these rules are suggestions rather than requirements. Furthermore, no attempt is made to completely specify the rendering; rather, enough information is given to make the intended effect of the various rendering attributes as clear as possible.
Many mathematical symbols such as an integral sign, a plus sign, or a parenthesis have a well-established, predictable, traditional notational usage. Typically, this usage amounts to certain default attribute values for either the <MO> or <MF> schema. Since these defaults vary from symbol to symbol, MathML anticipates that renderers will have a "dictionary" of default attributes for operators and fences (See Appendix C). If an operator or fence is not listed in the dictionary, the default values shown in parentheses in the table of attributes for <MO> should be used, since they are typically acceptable for a generic operator.
Some operators are overloaded in the sense that they can occur in
more than one form (prefix, infix, or postfix; open or close for
fences), with possibly different rendering properties for each form.
For example, "+" can be either a prefix or an infix
operator. Typically, a visual renderer would add space around both
sides of an infix operator, while only on the left of a prefix
operator. The "form" attribute allows specification of
which form to use, in case more than one form is possible according to
the operator dictionary. If there is more than one possible form and
no form attribute is given, a renderer may choose what form to
use. Typically, this would be determined as follows:
If the operator does not have attributes for the specified form in the dictionary, the renderer may use any of the forms which are available. All operators in the dictionary must have at least one possible form.
There is one exception to the above rules: an operator
which is "embellished" by one or more nested
subscripts, superscripts, surrounding text or whitespace, or
style changes. It is the embellished operator as a
whole whose position in an mrow is examined by the above rules
and whose surrounding spacing is affected by its form, in a
typical renderer, not the <MO> element
itself. E.g., the "+"4 in should be considered an infix
operator.
The precise definition of an embellished operator is: an <MO> or <MF> element; or one of the elements <MSTYLE>, <MPHANTOM>, <MSUB>, <MSUP>, <MSUBSUP>, <MUNDER>, <MOVER>, <MUNDEROVER>, <MMULTISCRIPTS>, or <MFRAC>, whose first subexpression exists and is an embellished operator; or an <MROW> element directly containing one embellished operator, whose other direct subexpressions are all space-like elements (see <MTEXT> section). Note that this definition permits nested embellishment only when there are no intervening enclosing elements not in the above list. Fences are included because this definition also affects the use of the stretchy attributes, which are present on both <MO> and <MF>.
The above rules are chosen so that in all ordinary cases it will not be necessary to specify a form attribute.
The amount of space added around an operator or fence when it occurs in an <MROW> can be specified by the lspace and rspace attributes. These numbers are given in ems. By convention, operators that tend to bind tightly to their arguments have smaller values for spacing than operators that tend to bind less tightly. This convention should be followed in the operator dictionary. In TeX, these values are limited to 3/18em, 4/18em, and 5/18em; MathML does not impose this limit. Non-graphical renderers should treat spacing attributes, and other rendering attributes described here, in analogous ways for their rendering medium.
Four attributes govern whether and how an operator or fence character stretches so that it matches the size of other elements: stretchy, symmetric, maxsize, and minsize. If an operator or fence has the attribute stretchy="true", then it obeys the stretching rules listed below, given the constraints imposed by the fonts and font rendering system. The minsize and maxsize attributes also limit the size. These two attributes are given as multipliers of the font's size. For example, if a character has maxsize="3", then it can grow to be no more than three times its normal size. The symmetric attribute governs whether the height and depth above and below the axis of the character are forced to be equal (by forcing both height and depth to become the maximum of the two). The symmetric attribute only applies to characters that stretch vertically.
Example: set maximum size of a parenthesis so that it
does not grow even though its default value is
stretchy="true".
<MROW> <MF maxsize="1"> ( </MF> <MFRAC><MI>a</MI><MI>b</MI></MFRAC> <MF maxsize="1"> ) </MF> </MROW>should render as
![[Graphics:presentationgr2.gif]](presentationgr2.gif)
as opposed to the default
rendering as ![[Graphics:presentationgr3.gif]](presentationgr3.gif)
. This could also have
been written using the <MSTYLE> element
discussed below (see the example there).
By default, most fences stretch vertically. Also, operators such as ∑, ∫, /, and vertical arrows stretch by default.
By default, most horizontal arrows and some accents stretch horizontally.
If a stretchy operator is not required to stretch (i.e. if it is not in one of the locations mentioned above, or if there are no other expressions whose size it should stretch to match, or if all such other expressions are themselves stretchy), then it has the standard (unstretched) size determined by the font.
The rules for the horizontal stretchiness inside scripts make the following work:
<MROW>
<MI>x</MI>
<MOVER>
<MO>→</MO>
<MTEXT>maps to</MTEXT>
</MOVER>
<MI>y</MI>
</MROW>
This displays as ![[Graphics:presentationgr4.gif]](presentationgr4.gif)
. The rules for
matrices allow arrows to stretch for use in commutative diagrams laid
out as matrices.
The largeop attribute specifies whether the operator should be drawn large if displaystyle="true" and scriptlevel="0". This corresponds to TeX's \displaystyle; MathML uses two attributes (displaystyle and scriptlevel) to control orthogonal presentation features that TeX encodes into one "style" attribute with values \displaystyle, \textstyle, \scriptstyle, and \scriptscriptstyle. MathML's scriptlevel attribute is discussed further in the section describing the <MSTYLE> element. Examples of large operators include ∫ and ∏.
The movablelimits attribute specifies whether underscripts and overscripts should be drawn as subscripts and superscripts when the scriptlevel attribute is > 0 or displaystyle="false". Movablelimits="false" means that underscripts and overscripts should never be drawn as subscripts and superscripts. By default, displaystyle="true" for displayed math and displaystyle="false" for inline math. Thus, operators with movablelimits="true" will display with limits (i.e., underscripts and overscripts) in displayed math and with subscripts and superscripts in inline math. Examples of operators that typically have movablelimits="true" are ∑, ∏, and "lim".
An <MTEXT> token can be used to represent arbitrary text which should be rendered as itself, but which should not affect in any way the mathematical content of the containing expression.
This element is often used to contain "renderable whitespace", i.e., invisible characters which are intended to alter the positioning of surrounding elements. In non-graphical media, such characters are intended to have an analogous effect, such as introducing positive or negative time delays or affecting rhythm in an audio renderer. This is not related to any whitespace in the source MathML which consists of blanks, newlines, and tabs. Blanks, newlines, and tabs present directly in the source are collapsed, according to the rules of an XML parser; they must be represented by entity references if it is desired to avoid this collapsing.
Renderable whitespace can have a positive or negative width as in "&thinspace;" and "&negativethinspace;", or zero width as in "&zerowidthspace;". The complete list of such characters is given in section 6. Note that there is no formal distinction in MathML between renderable whitespace characters and any other kinds of characters, in <MTEXT> or in any other element.
Renderable whitespace can also include characters that affect alignment or linebreaking. Some of these characters include:
| entity name | purpose (rough description) |
| NewLine | start a new line -- don't indent |
| IndentingNewLine | start a new line -- indent |
| NoBreak | do not allow a linebreak here |
| GoodBreak | if a linebreak is needed on the line, here is a good spot |
| BadBreak | if a linebreak is needed on the line, try to avoid breaking here |
| AlignmentMarker | align this vertically with the same character in adjacent lines |
For the complete list of MathML entities, and a discussion of their use, consult section 6.
Same as for identifier.
Use of "space-like elements", i.e. <MTEXT>, <MSPACE/>, or <MPHANTOM>, as arguments of some element which requires a specific number of arguments, or interprets different argument positions differently, does not permit that element to have the wrong number of arguments or to interpret the argument positions abnormally (e.g. by ignoring the using up of an argument position by a space-like element). Instead, space-like elements should be grouped with a neighboring element by introducing an <MROW> for that purpose. For example:
<MFRAC>
<MROW>
<MTEXT> &thickspace;
</MTEXT>
<MI>a</MI>
</MROW>
<MI>b</MI>
</MFRAC>
<MTEXT>Theorem 1:</MTEXT>
<MTEXT>&thinspace;</MTEXT>
<MTEXT>&alignmentmarker;&thickspace;
</MTEXT>
<MTEXT>/* a comment */</MTEXT>
An <MSPACE/> empty element represents a blank space of any desired size, as set by its attributes. The default value for each attribute is 0, so it will not be useful without some attributes specified.
| Name | values | default | |
| width | number (ems) | 0 | |
| height | number (exs) | 0 | |
| depth | number (exs) | 0 | |
| background | #rrggbb | inherited |
See also the comments about "space-like elements" given under <MTEXT>.
<MS> is used to represent "string literals" in expressions meant to be interpreted by computer algebra systems or other systems with "programming languages". No extra spacing is added around rendered string literals, but they are typically rendered with surrounding double quotes. <MS>, like all elements, does collapse whitespace in its content according to the rules of XML, so blanks, tabs, or newlines in the content should be encoded as entity references.
As explained below, most text embedded in a mathematical expression should be marked up with <MTEXT>, or perhaps <MO> or <MI>, rather than <MS>.
Same as for identifier along with
| Name | values | default | |
| lquote | string | " | |
| rquote | string | " |
By default, string literals are displayed surrounded by double quotes. The characters used can be changed with the lquote and rquote attribute.
Most text embedded in math may seem like a string literal at first
glance. However, it is usually the case that it is more correctly
represented (and will be better displayed) as an operator, identifier,
or <MTEXT> element. E.g., the expression "
![[Graphics:presentationgr5.gif]](presentationgr5.gif)
"
is equivalent to "
![[Graphics:presentationgr6.gif]](presentationgr6.gif)
"
and can be represented as:
<MROW>
<MO> there exists
</MO>
<MROW>
<MROW>
<MI>
δ</MI>
<MO>
></MO>
<MN>
0</MN>
</MROW>
<MO> such
that</MO>
<MROW>
<MROW>
<MI>f</MI>
<MO>⁡</MO>
<MROW>
<MF>(</MF>
<MI>x</MI>
<MF>)</MF>
</MROW>
</MROW>
<MO><
</MO>
<MN>1</MN>
</MROW>
</MROW>
</MROW>
An example involving a <MI> tag is:
![[Graphics:presentationgr7.gif]](presentationgr7.gif)
In this example, ellipsis should be represented using an <MI> element,
since it takes the place of a term in the sum.
As a final example, expository text (which is probably best not included in a math element at all), is best represented with an <MTEXT> element. An example of this is:
![[Graphics:presentationgr9.gif]](presentationgr9.gif)
![[Graphics:presentationgr8.gif]](presentationgr8.gif)
In this example, "Theorem 1:" can use an <MTEXT> element. The "If" and "then" together mean "implies" and thus might use an operator element. However, they too might be considered ordinary text. The example is probably best rendered with only the two inequalities represented as MathML at all, letting the text be part of the surrounding HTML.
These elements allow any single element as their content.
<MSTYLE> is used to make style changes in its content. The changes affect the context inherited by all contained subexpressions except where overridden by some automatic or explicit change to some attribute, as discussed for each element individually.
All attributes can be given. In addition to those listed for any specific elements:
| Name | values | default | |
| scriptlevel | number | automatic | |
| displaystyle | true | false | automatic | |
| scriptsizemultiplier | number | 0.71 | |
| scriptminsize | number (pts) | 8 |
"scriptlevel" is an extension of TeX's \displaystyle, \scriptstyle, etc. "scriptlevel" is automatically incremented by various elements which typically display some or all of their arguments in smaller type, including elements for scripts, fractions, roots, and matrices. The scriptlevel attribute works with the scriptsizemultiplier and scriptminsize attributes to adjust font sizes used for displaying scripts. A scriptsizemultiplier="1" would cause scripts never to shrink. Any automatic script size change is limited by scriptminsize. This prevents scripts from becoming unreadably small.
The example of limiting the stretchiness of a parenthesis shown in the section on rendering rules for <MO> and <MF> can be rewritten using <MSTYLE> as:
<MSTYLE maxsize="1">
<MROW>
<MF>(</MF>
<MFRAC><MI>a</MI>
<MI>b</MI></MFRAC>
<MF>)</MF>
</MROW>
</MSTYLE>
Note that the width, height, and depth attributes, defined on <MPHANTOM>, can be given on <MSTYLE> to change its rendered size in the same way as for <MPHANTOM>. If they are made smaller than the normal rendered values for the content (which can depend on the renderer), the content is "clipped" (not shrunk), on the top, bottom, or right edges for height, depth, and width respectively. If they are made larger, extra space is added on the same edges; the content is not "stretched". For audio renderers, duration corresponds to horizontal space (width).
Display the contents as a syntax error message. This might be done, for example, by displaying the contents in red, flashing the contents, or changing the background color. The contents can be any expression.
The intent of this element is to provide a way for other applications that generate MathML from other input to report on syntax errors. Since one of the planned extension mechanisms for MathML is to allow preprocessors to parse alternative input syntaxes designed for easy hand entry, it is important that preprocessors have the ability to indicate that a syntax error occurred at a certain point, by replacing the erroneous part of the input with an <MERROR> element containing a description of the error, while processing the surrounding expressions normally; this makes it easier for an author to determine from the rendered output what portion of the input was in error.
None (except attributes allowed for all elements)
<MPHANTOM> renders invisibly, but with the same size and other dimensions (such as baseline position) that its contents would have if they were rendered normally. Like all space-like elements (see <MTEXT>), it has no mathematical meaning. <MPHANTOM> can be used to align parts of an expression by invisibly duplicating subexpressions.
| Name | values | default | |
| width | number (ems) | same as content | |
| height | number (exs) | same as content | |
| depth | number (exs) | same as content |
The attributes can be used to change the dimensions to some other value. This is useful mainly to set certain dimensions to 0. "height" and "depth" specify the extent above and below the baseline respectively. Setting the width, height, or depth to 0 is useful for forcing horizontal (or vertical) alignment without affecting vertical (or horizontal) alignment.
See also the comments about "space-like elements" given under <MTEXT>.
An <MROW> is used to horizontally group any number of subexpressions. Subexpressions should be grouped by the document author in a manner similar to some notion of an underlying syntax tree. Operators and their arguments should occur in a single <MROW>; more than one operator should occur in one <MROW> only when the operators are of the same type (see Appendix C) and can be considered to act together on the interleaved arguments (e.g. for chains of relational operators), and given that, whenever no more refined subexpression structure is desired to be expressed. Otherwise, nested <MROW>s should be used. Matching fences (such as parentheses) and the expression they enclose should occur as the only three non-space-like arguments of one <MROW>.
These rules for grouping are conventional; although the choice of grouping will affect details of the appearance and possibly of subsequent interpretation, any grouping is allowed.
Proper grouping has three purposes: it improves display (affects spacing); it allows for intelligent linebreaking and indentation; it simplifies possible semantic interpretation of presentation by computer algebra systems or macro packages (including interpretation which is helpful for audio rendering).
None (except attributes allowed for all elements)
As an example, ![[Graphics:presentationgr10.gif]](presentationgr10.gif)
should be written as:
<MROW>
<MROW>
<MN>2</MN>
<MO>
⁢ </MO>
<MI>x</MI>
</MROW>
<MO> + </MO>
<MI>y</MI>
<MO> - </MO>
<MI>z</MI>
</MROW>
This schema is used for fractions. It can also be used to mark up fraction-like objects such as binomial coefficients and Legendre symbols. The syntax for <MFRAC> is
<MFRAC> numerator denominator </MFRAC>
| Name | values | default | |
| linethickness | number | 1 (rule thickness) |
A fraction with linethickness="0" might be used for binomials. A linethickness greater than one might be used with nested fractions. These cases are shown below:
![[Graphics:presentationgr11.gif]](presentationgr11.gif)
<MSQRT> base </MSQRT>
<MROOT> base index </MROOT>
None.
The elements described in this section position one or more scripts around a base. Attaching various kinds of scripts and embellishments to symbols is a very common notational device in mathematics. For purely visual layout, a single general-purpose schema could suffice for positioning scripts and embellishments in any of the traditional script locations around a given base. However, in order to better capture the abstract structure of common notation, MathML provides several more specialized scripting schema.
In addition to sub/superscript schema, over/underscript elements place scripts above and below the base. These elements can be used to place limits on large operators, or for placing accents and lines above or below the base. The rules for rendering accents differ from those for overscripts and underscripts, and this difference can be controlled with the "accent" and "accentunder" attributes, as described in the appropriate sections below.
MathML also provides a schema for tensor indices. Tensor indices are distinct from ordinary sub- and superscripts in that they must align in vertical columns. Tensor indices can also occur in prescript positions.
Because presentation tags should be used to describe the abstract
notational structure of expressions, it is important that the base
expression in all scripting schema should be the entire expression
that is being scripted, not just the rightmost character. For
example,
![[Graphics:presentationgr12.gif]](presentationgr12.gif)
should be written as:
<MSUP>
<MROW>
<MF> ( </MF>
<MROW>
<MI>x</MI>
<MO> + </MO>
<MI>y</MI>
</MROW>
<MF> ) </MF>
</MROW>
<MN>2</MN>
</MSUP>
The usage for the <MSUB> element is
<MSUB> base subscript </MSUB>
| Name | values | default | |
| subscriptshift | number (exs) | automatic |
The subscriptshift attribute specifies the minimum amount to shift the baseline of subscript down.
The usage for the <MSUP> element is
<MSUP> base superscript </MSUP>
| Name | values | default | |
| superscript shift | number (exs) | automatic |
The superscriptshift attribute specifies the minimum amount to shift the baseline of superscript up.
The <MSUBSUP> element is used so that the subscript and superscript are both tight against the base, i.e. vertically aligned as in the second case shown here:
![[Graphics:presentationgr13.gif]](presentationgr13.gif)
The usage for the <MSUBSUP> element is
<MSUBSUP> base subscript superscript </MSUBSUP>
| Name | values | default | |
| subscriptshift | number (exs) | automatic | |
| superscriptshift | number (exs) | automatic |
One use of the <MSUBSUP> element is for placing limits on certain large operators (as embellishments). For example, the integral
![[Graphics:presentationgr14.gif]](presentationgr14.gif)
would be represented as
<MROW>
<MSUBSUP>
<MO>
∫ </MO>
<MN> 0 </MN>
<MN> 1 </MN>
</MSUBSUP>
<MROW>
<MSUP>
<MI>
ⅇ </MI>
<MI> x </MI>
</MSUP>
<MO> ⁢ </MO>
<MROW>
<MO> ⅆ </MO>
<MI>x
</MI>
</MROW>
</MROW>
</MROW>
The usage for the <MUNDER> element is
<MUNDER> base underscript </MUNDER>
| Name | values | default | |
| accentunder | true | false | false |
The accentunder attribute controls whether underscript is drawn as an "accent" or as a limit. These differences are described in the <MOVER> section. Below is an example (accent vs underscript):
![[Graphics:presentationgr15.gif]](presentationgr15.gif)
If the base is an operator with movablelimits="true", and displaystyle="false" or scriptlevel > 0, then underscript is drawn in a subscript position. This is often used for limits on symbols such as ∑.
The usage for the <MOVER> element is
<MOVER> base overscript </MOVER>
| Name | values | default | |
| accent | true | false | false |
The accent attribute controls whether overscript is drawn as an accent or as a limit. The main difference between an accent and a limit is that the limit is reduced in size whereas an accent (i.e. diacritical mark) is the same size as the base. A second difference is that the diacritical mark is drawn closer to the base. This is shown below (accent vs limit):
![[Graphics:presentationgr16.gif]](presentationgr16.gif)
These differences also affect lines:
![[Graphics:presentationgr17.gif]](presentationgr17.gif)
If the base is an operator with movablelimits="true", and displaystyle="false" or scriptlevel > 0, then overscript is drawn in a superscript position. This is often used for limits on symbols such as ∑.
The usage for the <MUNDEROVER> element is
<MUNDEROVER> base underscript overscript </MUNDEROVER>
| Name | values | default | |
| accent | true | false | false | |
| accentunder | true | false | false |
The <MUNDEROVER> element is used so that the underscript and overscript are vertically spaced equally in relation to the base and so that they follow the slant of the base as in the second example below:
![[Graphics:presentationgr18.gif]](presentationgr18.gif)
The difference in the vertical spacing is too small to be noticed on a low resolution display at a normal font size, but is noticeable on a higher resolution device such as a printer and when using large font sizes. In addition to the visual differences, attaching both the underscript and overscript to the same base more accurately reflects the semantics of the expression.
If the base is an operator with movablelimits="true", and displaystyle="false" or scriptlevel > 0, then underscript and overscript are drawn in a subscript and superscript position. This is often used for limits on symbols such as ∑.
The usage for the <MMULTISCRIPTS> element is
<MMULTISCRIPTS> base postscriptpairs [ <MPRESCRIPTS/> prescriptpairs ] </MMULTISCRIPTS>
Presubscripts and tensor notations are represented by a single element, <MMULTISCRIPTS>. This element allows the representation of any number of vertically-aligned pairs of subscripts and superscripts, attached to one base expression. It supports both postscripts (to the right of the base in visual notation) and prescripts (to the left of the base in visual notation). Missing scripts can be represented by the empty element <NONE/>.
The prescripts are optional, and when present are given after the postscripts, because prescripts are relatively rare compared to tensor notation.
The argument sequence consists of the base followed by zero or more pairs of vertically-aligned subscripts and superscripts (in that order) that represent all of the postscripts. This list is optionally followed by an empty element <MPRESCRIPTS/> and a list of zero or more pairs of vertically-aligned presubscripts and presuperscripts that represent all of the prescripts. The pair lists for postscripts and prescripts are given in a left-to-right order. If no subscript or superscript should be rendered in a given position, then the empty element <NONE/> should be used in that position.
The base, subscripts, superscripts, the optional separator element <MPRESCRIPTS/>, the presubscripts, and the presuperscripts, are all direct arguments to the <MMULTISCRIPTS> element (i.e. they are all at the same level of the expression tree). Whether a script argument is a subscript or a superscript (or, if it follows <MPRESCRIPTS/>, whether it is a presubscript or a presuperscript) is determined by whether it occurs in an even-numbered or odd-numbered argument position, respectively, ignoring the empty element <MPRESCRIPTS/> itself when determining the position. (The first argument, the base, is considered to be in position 1.) The total number of arguments must be odd, if <MPRESCRIPTS/> is not given, or even, if it is.
The empty elements <MPRESCRIPTS/> and <NONE/> are only allowed as direct arguments to <MMULTISCRIPTS>.
Same as <MSUBSUP>.
Two examples of the use of <MMULTISCRIPTS> are:
![[Graphics:presentationgr19.gif]](presentationgr19.gif)
<MROW>
<MMULTISCRIPTS>
<MI>F</MI>
<MN>1</MN>
<NONE/>
<MPRESCRIPTS/>
<MN>0</MN>
<NONE/>
</MMULTISCRIPTS>
<MO>⁡</MO>
<MROW>
<MF>(</MF>
<MROW>
<MO>;</MO>
<MI>a</MI>
<MO>;</MO>
<MI>z</MI>
</MROW>
<MF>)</MF>
</MROW>
</MROW>
![[Graphics:presentationgr20.gif]](presentationgr20.gif)
<MMULTISCRIPTS>
<MI>R</MI>
<MI>i</MI>
<NONE/>
<NONE/>
<MI>j</MI>
<MI>k</MI>
<NONE/>
<MI>l</MI>
<NONE/>
</MMULTISCRIPTS>
Matrices, arrays and other table-like mathematical notation are marked up using <MTABLE>, <MTR> and <MTD> tags. These elements are similar to the <TABLE>, <TR> and <TD> elements of HTML, except that they provide substantially more attributes in order to provide the fine layout control necessary for commutative diagrams, block matrices and so on.
A matrix or table is specified using the <MTABLE> element. Inside of the <MTABLE> element, <MTR> and <MTD> elements can be given. If some argument to <MTABLE> is not a <MTR> element, renderers should assume a one column row (i.e. the argument is effectively wrapped with an inferred <MTR> begin-end tag pair). Similarly, if some argument to a (possibly inferred) <MTR> element is not a <MTD> element, that argument should be treated as a matrix entry by effectively wrapping it with an inferred <MTD> begin-end tag pair. Matrix rows that have fewer columns than other rows of the same matrix (whether the other rows precede or follow them) are effectively padded on the right with invisible elements so that the number of columns equals the maximum number of columns in any of the <MTR> elements in that matrix.
| Name | values | default | |
| align | top | bottom | center | baseline | axis | axis | |
| rowalign | (top | bottom | center | baseline | axis)+ | baseline | |
| columnalign | (left | center | right)+ | center | |
| rowspacing | (number)+ (exs) | 1.0 | |
| columnspacing | (number)+ (ems) | 0.8 | |
| rowlines | (none | solid | dashed)+ | none | |
| columnlines | (none | solid | dashed)+ | none | |
| frame | none | solid | dashed | none | |
| framespacing | number number (ems exs) | "0.4 0.5" | |
| equalrows | true | false | true | |
| equalcolumns | true | false | true |
Note: the notation "(x | y)+" means one or more occurrences of either x or y, separated with whitespace. For example, possible values for columnalign are "left", "left left", and "left right center center" If there are more entries than are necessary (e.g., more entries than columns for columnalign), then only the first entries will be used. If there are fewer entries, then the last entry is repeated as often as necessary. For example, if columnalign="right center" and the matrix has three columns, the first column will be right aligned and the second and third columns will be centered.
The align attribute specifies where to align the matrix with respect to its environment. "axis" means to align the center of the matrix on the environment's axis. (The axis of an equation is an alignment line used by typesetters. It is the line on which a minus sign typically lies.) "center" and "baseline" both mean to align the center of the matrix on the environment's baseline. "top" or "bottom" aligns the top or bottom of the matrix on the environment's baseline.
The rowalign attribute specifies how the entries in each row should be aligned. For example, "top" means that the tops of each entry in each row should be aligned with the tops of the other entries in that row. The columnalign attribute specifies how the entries in each column should be aligned.
The rowspacing and columnspacing attributes specify how much space should be added between each row and column. However, spacing before the first row and after the last row (i.e. at the top and bottom of the matrix) is given by the second number in the value of the framespacing attribute, and spacing before the first column and after the last column (i.e. on the left and on the right of the matrix) is given by the first number in the value of the framespacing attribute.
The rowlines and columnlines attributes specify whether and what kind of lines should be added between each row and column. Lines before the first row or column and after the last row or column are given using the frame attribute.
If a frame is desired around the matrix, the frame attribute is used. If the attribute value is not "none", then framespacing is used to add spacing between the lines of the frame and the first and last rows and columns of the matrix. If frame="none", then the framespacing attribute is ignored. The frame and framespacing attributes are not part of the rowlines/columnlines, rowspacing/columnspacing options because having them be so would often require that rowlines and columnlines would need to be fully specified instead of just giving a single value. For example, if a matrix had five columns and we wanted lines between the columns, but no frame, then we would have to write columnlines="none solid solid solid solid none". By separating the frame from the internal lines, we only need to write columnlines="solid".
The equalrows attribute (if true) forces the rows all to be the same total height. The equalcolumns attribute (if true) forces the columns all to be the same width.
This element is only valid within an <MTABLE> element and specifies that the contents should be a row of the matrix.
| Name | values | default | |
| rowalign | top | bottom | center | baseline | axis | inherited | |
| columnalign | (left | center | right)+ | inherited |
The rowalign and columnalign attributes allow a specific row to override the alignment specified by the same attributes in the surrounding <MTABLE> element.
This element is only allowed within an <MTR> element (perhaps an inferred one).
| Name | values | default | |
| rowspan | number | 1 | |
| columnspan | number | 1 | |
| rowalign | top | bottom | center | baseline | axis | inherited | |
| columnalign | left | center | right | inherited |
The rowspan and columnspan attributes allow a specific matrix element to be treated as if it occupied the number of rows or columns specified. The interpretation of how this larger element affects specifying subsequent rows and columns is meant to correspond with the similar attribute for HTML 3.2 tables.
The rowalign and columnalign attributes allow a specific matrix element to override the alignment specified by a surrounding <MTABLE> or <MTR> element.