MathML Core

MathML specifies a single top-level or root math element, which encapsulates each instance of MathML markup within a document. All other MathML content must be contained in a <math> element.

The <math> element accepts the attributes described in 2.1.3 Global Attributes as well as the following attributes:

• display
• alttext

The display attribute, if present, must be an ASCII case-insensitive match to block or inline. The user agent stylesheet described in A. User Agent Stylesheet contains rules for this attribute that affect the default values for the display (block math or inline math) and math-style (normal or compact) properties. If the display attribute is absent or has an invalid value, the User Agent stylesheet treats it the same as inline.

This specification does not define any observable behavior that is specific to the alttext attribute.

If the <math> element does not have its computed display property equal to block math or inline math then it is laid out according to the CSS specification where the corresponding value is described. Otherwise the layout algorithm of the mrow element is used to produce a math content box. That math content box is used as the content for the layout of the element, as described by CSS for display: block (if the computed value is block math) or display: inline (if the computed value is inline math). Additionally, if the computed display property is equal to block math then that math content box is rendered horizontally centered within the content box.

In the following example, a math formula is rendered in display mode on a new line and taking full width, with the math content centered within the container:

<div style="width: 15em;"> This mathematical formula with a big summation and the number pi <math display="block" style="border: 1px dotted black;"> <mrow> <munderover> <mo>∑</mo> <mrow><mi>n</mi><mo>=</mo><mn>1</mn></mrow> <mrow><mo>+</mo><mn>∞</mn></mrow> </munderover> <mfrac> <mn>1</mn> <msup><mi>n</mi><mn>2</mn></msup> </mfrac> </mrow> <mo>=</mo> <mfrac> <msup><mi>π</mi><mn>2</mn></msup> <mn>6</mn> </mfrac> </math> is easy to prove. </div>

As a comparison, the same formula would look as follows in inline mode. The formula is embedded in the paragraph of text without forced line breaking. The baselines specified by the layout algorithm of the mrow are used for vertical alignment. Note that the middle of sum and equal symbols or fractions are all aligned, but not with the alphabetical baseline of the surrounding text.

Because good mathematical rendering requires use of mathematical fonts, the user agent stylesheet should set the font-family to the math value on the <math> element instead of inheriting it. Additionally, several CSS properties that can be set on a parent container such as font-style, font-weight, direction or text-indent etc are not expected to apply to the math formula and so the user agent stylesheet has rules to reset them by default.

math { direction: ltr; text-indent: 0; letter-spacing: normal; line-height: normal; word-spacing: normal; font-family: math; font-size: inherit; font-style: normal; font-weight: normal; display: inline math; math-shift: normal; math-style: compact; math-depth: 0; } math[display="block" i] { display: block math; math-style: normal; } math[display="inline" i] { display: inline math; math-style: compact; }

In addition to CSS data types, some MathML attributes rely on the following MathML-specific types:

unsigned-integer

An <integer> value as defined in [CSS-VALUES-4], whose first character is neither U+002D HYPHEN-MINUS character (-) nor U+002B PLUS SIGN (+).

boolean

A string that is an ASCII case-insensitive match to true or false.

The following attributes are common to and may be specified on all MathML elements:

• autofocus
• class
• data-*
• dir
• displaystyle
• id
• mathbackground
• mathcolor
• mathsize
• nonce
• scriptlevel
• style
• tabindex
• on* event handler attributes
• additional attributes, as described in 2.1.7 Attributes Reserved as Valid

The id, class, style, data-*, autofocus and nonce and tabindex attributes have the same syntax and semantics as defined for id, class, style, data-*, autofocus, nonce and tabindex attributes on HTML elements.

The dir attribute, if present, must be an ASCII case-insensitive match to ltr or rtl. In that case, the user agent is expected to treat the attribute as a presentational hint setting the element's direction property to the corresponding value. More precisely, an ASCII case-insensitive match to rtl is mapped to rtl while an ASCII case-insensitive match to ltr is mapped to ltr.

In the following example, the dir attribute is used to render "𞸎 plus 𞸑 raised to the power of (٢ over, 𞸟 plus ١)" from right-to-left.

<math dir="rtl"> <mrow> <mi>𞸎</mi> <mo>+</mo> <msup> <mi>𞸑</mi> <mfrac> <mn>٢</mn> <mrow> <mi>𞸟</mi> <mo>+</mo> <mn>١</mn> </mrow> </mfrac> </msup> </mrow> </math>

All MathML elements support event handler content attributes, as described in event handler content attributes in HTML.

All event handler content attributes noted by HTML as being supported by all HTMLElements are supported by all MathML elements as well, as defined in the MathMLElement IDL.

The mathcolor and mathbackground attributes, if present, must have a value that is a <color>. In that case, the user agent is expected to treat these attributes as a presentational hint setting the element's color and background-color properties to the corresponding values. The mathcolor attribute describes the foreground fill color of MathML text, bars etc while the mathbackground attribute describes the background color of an element.

The mathsize attribute, if present, must have a value that is a valid <length-percentage>. In that case, the user agent is expected to treat the attribute as a presentational hint setting the element's font-size property to the corresponding value. The mathsize property indicates the desired height of glyphs in math formulas but also scales other parts (spacing, shifts, line thickness of bars etc) accordingly.

The displaystyle attribute, if present, must have a value that is a boolean. In that case, the user agent is expected to treat the attribute as a presentational hint setting the element's math-style property to the corresponding value. More precisely, an ASCII case-insensitive match to true is mapped to normal while an ASCII case-insensitive match to false is mapped to compact. This attribute indicates whether formulas should try to minimize the logical height (value is false) or not (value is true) e.g. by changing the size of content or the layout of scripts.

The scriptlevel attribute, if present, must have value +<U>, -<U> or <U> where <U> is an unsigned-integer. In that case the user agent is expected to treat the scriptlevel attribute as a presentational hint setting the element's math-depth property to the corresponding value. More precisely, +<U>, -<U> and <U> are respectively mapped to add(<U>) add(<-U>) and <U>.

displaystyle and scriptlevel values are automatically adjusted within MathML elements. To fully implement these attributes, additional CSS properties must be specified in the user agent stylesheet as described in A. User Agent Stylesheet. In particular, for all MathML elements a default font-size: math is specified to ensure that scriptlevel changes are taken into account.

In this example, an munder element is used to attach a script "A" to a base "∑". By default, the summation symbol is rendered with the font-size inherited from its parent and the A as a scaled down subscript. If displaystyle is true, the summation symbol is drawn bigger and the "A" becomes an underscript. If scriptlevel is reset to 0 on the "A", then it will use the same font-size as the top-level math root.

<math> <munder> <mo>∑</mo> <mi>A</mi> </munder> <munder displaystyle="true"> <mo>∑</mo> <mi>A</mi> </munder> <munder> <mo>∑</mo> <mi scriptlevel="0">A</mi> </munder> </math>

The attributes intent and arg are reserved as valid attributes.

This specification does not define any observable behavior that is specific to the intent and arg attributes.

MathML can be mixed with HTML and SVG as described in the relevant specifications [HTML] [SVG].

When evaluating the SVG requiredExtensions attribute, user agents must claim support for the language extension identified by the MathML namespace.

In this example, inline MathML and SVG elements are used inside an HTML document. SVG elements <switch> and <foreignObject> (with proper <requiredExtensions>) are used to embed a MathML formula with a text fallback, inside a diagram. HTML input element is used within the mtext to include an interactive input field inside a mathematical formula. See also 3.7 Semantics and Presentation for an example of SVG and HTML inside an annotation-xml element.

<svg style="font-size: 20px" width="400px" height="220px" viewBox="0 0 200 110"> <g transform="translate(10,80)"> <path d="M 0 0 L 150 0 A 75 75 0 0 0 0 0 M 30 0 L 30 -60 M 30 -10 L 40 -10 L 40 0" fill="none" stroke="black"></path> <text transform="translate(10,20)">1</text> <switch transform="translate(35,-40)"> <foreignObject width="200" height="50" requiredExtensions="http://www.w3.org/1998/Math/MathML"> <math> <msqrt> <mn>2</mn> <mi>r</mi> <mo>−</mo> <mn>1</mn> </msqrt> </math> </foreignObject> <text>\sqrt{2r - 1}</text> </switch> </g> </svg> <p> Fill the blank: <math> <msqrt> <mn>2</mn> <mtext><input onchange="..." size="2" type="text"></mtext> <mo>−</mo> <mn>1</mn> </msqrt> <mo>=</mo> <mn>3</mn> </math> </p>

User agents must support various CSS features mentioned in this specification, including new ones described in 4. CSS Extensions for Math Layout. They must follow the computation rule for display: contents.

In this example, the MathML formula inherits the CSS color of its parent and uses the font-family specified via the style attribute.

<div style="width: 15em; color: blue"> This mathematical formula with a big summation and the number pi <math display="block" style="font-family: STIX Two Math"> <mrow> <munderover> <mo>∑</mo> <mrow><mi>n</mi><mo>=</mo><mn>1</mn></mrow> <mrow><mo>+</mo><mn>∞</mn></mrow> </munderover> <mfrac> <mn>1</mn> <msup><mi>n</mi><mn>2</mn></msup> </mfrac> </mrow> <mo>=</mo> <mfrac> <msup><mi>π</mi><mn>2</mn></msup> <mn>6</mn> </mfrac> </math> is easy to prove. </div>

All documents containing MathML Core elements must include CSS rules described in A. User Agent Stylesheet as part of user-agent level style sheet defaults. In particular, this adds !important rules to force writing mode to horizontal-lr on all MathML elements.

The float property does not create floating of elements whose parent's computed display value is block math or inline math, and does not take them out-of-flow.

The ::first-line and ::first-letter pseudo-elements do not apply to elements whose computed display value is block math or inline math, and such elements do not contribute a first formatted line or first letter to their ancestors.

The following CSS features are not supported and must be ignored:

• Line breaking inside math formulas: white-space is treated as nowrap on all MathML elements.
• Alignment properties: align-content, justify-content, align-self, justify-self have no effects on MathML elements.

User agents supporting Web application APIs must ensure that they keep the visual rendering of MathML synchronized with the [DOM] tree, in particular perform necessary updates when MathML attributes are modified dynamically.

All the nodes representing MathML elements in the DOM must implement, and expose to scripts, the following MathMLElement interface.

WebIDL[Exposed=Window] interface MathMLElement : Element { }; MathMLElement includes GlobalEventHandlers; MathMLElement includes HTMLOrForeignElement;

The GlobalEventHandlers and HTMLOrForeignElement interfaces are defined in [HTML].

In the following example, a MathML formula is used to render the fraction "α over 2". When clicking the red α, it is changed into a blue β.

<script> function ModifyMath(mi) { mi.style.color = 'blue'; mi.textContent = 'β'; } </script> <math> <mrow> <mfrac> <mi style="color: red" onclick="ModifyMath(this)">α</mi> <mn>2</mn> </mfrac> </mrow> </math>

Because math fonts generally contain very tall glyphs such as big integrals, using typographic metrics is important to avoid excessive line spacing of text. As a consequence, user agents must take into account the USE_TYPO_METRICS flag from the OS/2 table [OPEN-FONT-FORMAT] when performing text layout.

MathML provides the ability for authors to allow for interactivity in supporting interactive user agents using the same concepts, approach and guidance to Focus as described in HTML, with modifications or clarifications regarding application for MathML as described in this section.

When an element is focused, all applicable CSS focus-related pseudo-classes as defined in Selectors Level 3 apply, as defined in that specification.

The contents of embedded math elements (including HTML elements inside token elements) contribute to the sequential focus order of the containing owner HTML document (combined sequential focus order).

The default display property is described in A. User Agent Stylesheet:

• For the <math> root, it is equal to inline math or block math according to the value of the display attribute.
• For Tabular MathML elements mtable, mtr, mtd it is respectively equal to inline-table, table-row and table-cell.
• For all but the first children of the maction and semantics elements, it is equal to none.
• For all the other MathML elements it is equal to block math.

In order to specify math layout in different writing modes, this specification uses concepts from [CSS-WRITING-MODES-4]:

• abstract dimensions: block dimension, inline dimension, block axis, inline axis, block size, inline size.
• flow-relative directions: inline-start, inline-end, block-start.
• line-relative directions: line-left, line-over, line-under.

Boxes used for MathML elements rely on several parameters in order to perform layout in a way that is compatible with CSS but also to take into account very accurate positions and spacing within math formulas:

1. Inline metrics. min-content inline size, max-content inline size and inline size from CSS. See Figure 1.

   

2. Block metrics. The block size, first baseline set and last baseline set. The following baselines are defined for MathML boxes:

   1. The alphabetic baseline which typically aligns with the bottom of uppercase Latin glyphs. The algebraic distance from the alphabetic baseline to the line-over edge of the box is called the line-ascent. The algebraic distance from the line-under edge to the alphabetic baseline of the box is called the line-descent.
   2. The mathematical baseline, also called math axis, which typically aligns with the fraction bar, middle of fences and binary operators. It is shifted away from the alphabetic baseline by AxisHeight towards the line-over.
   3. The ink-over baseline, indicating the line-over theorical limit of the math content drawn, excluding any extra space. If not specified, it is aligned with the line-over edge. The algebraic distance from the alphabetic baseline to the ink-over baseline is called the ink line-ascent.
   4. The ink-under baseline, indicating the line-under theorical limit of the math content drawn, excluding any extra space. If not specified, it is aligned with the line-under edge. The algebraic distance from the ink-under baseline to the alphabetic baseline is called the ink line-descent.
   Note

   For math layout, it is very important to rely on the ink extent when positioning text. This is not the case for more complex notations (e.g. square root). Although ink-ascent and ink-descent are defined for all MathML elements they are really only used for the token elements. In other cases, they just match normal ascent and descent.
   Unless specified otherwise, the last baseline set is equal to the first baseline set for MathML boxes.
3. An optional italic correction which provides a measure of how much the text of a box is slanted along the inline axis. See Figure 2.

   

   If it is requested during calculation of min-content inline size and max-content inline size or during layout then 0 is used as a fallback value.
4. An optional top accent attachment which provides a reference offset on the inline axis of a box that should be used when positioning that box as an accent. See Figure 3.

   

   If it is requested during calculation of min-content inline size (respectively max-content inline size) then half the min-content inline size (respectively max-content inline size) is used as a fallback value. If it is requested during layout then half the inline size of the box is used as a fallback value.

Given a MathML box, the following offsets are defined:

• The inline offset of a child box is the offset between the inline-start edge of the parent box and the inline-start edge of the child box.
• The block offset of a child box is the offset between the block-start edge of the parent box and the block-start edge of the child box.
• The line-left offset of a child box is the offset between the line-left edge of the parent box and the line-left edge of the child box.

Each MathML element has an associated math content box, which is calculated as described in this chapter's layout algorithms using the following structure:

1. Calculation of min-content inline size and max-content inline size of the math content.
2. Box layout:
   1. Layout of in-flow child boxes.
   2. Calculation of inline size, ink line-ascent, ink line-descent, line-ascent and line-ascent of the math content.
   3. Calculation of offsets of child boxes within the math content box as well as sizes and offsets of extra graphical items (bars, radical symbol, etc).
   4. Layout and positioning of absolutely-positioned and fixed-positioned boxes, as described in [CSS-POSITION-3].

The following extra steps must be performed:

• After calculating the line-ascent and line-descent of a math content box, its block size is set to their sum.
• By default, the box metrics, offsets, baselines, italic correction and top accent attachment of the content box are set to the one calculated for the math content box. However if a different size is specified for the content box (via width, height or related properties), that size is used instead and the inline-start and block-start edges of the math content box are aligned with the ones of the content box, unless otherwise specified in a specific layout algorithm.

• The box metrics and offsets of the padding box are obtained from the content box by taking into account the corresponding padding properties as described in CSS.

  The baselines of the padding box are the same as the one of the content box.

  If the content box has a top accent attachment then the padding box has the same property, increased by the inline-start padding. If the content box has an italic correction then the padding box has the same property, increased by the inline-end padding.

• The box metrics and offsets of the border box are obtained from the padding box by taking into account the corresponding border-width property as described in CSS.

  In general, the baselines of the border box are the same as the one of the padding box. However, if the line-over border is positive then the ink-over baseline is set to the line-over edge of the border box and if the line-under border is positive then the ink-under baseline is set to the line-under edge of the border box.

  If the padding box has a top accent attachment then the border box has the same property, increased by the border-width of its inline-start egde. If the padding box has an italic correction then the border box has the same property, increased by the border-width of its inline-end egde.

• The box metrics and offsets of the margin box are obtained from the border box by taking into account the corresponding margin properties as described in CSS.

  The baselines of the margin box are the same as the one of the border box.

  If the padding box has a top accent attachment then the margin box has the same property, increased by the inline-start margin. If the padding box has an italic correction then the margin box has the same property, increased by the inline-end margin.

During box layout, optional inline stretch size constraint and block stretch size constraint parameters may be used on embellished operators. The former indicates a target size that a core operator stretched along the inline axis should cover. The latter indicates an ink line-ascent and ink line-descent that a core operator stretched along the block axis should cover. Unless specified otherwise, these parameters are ignored during box layout and child boxes are laid out without any stretch size constraint.

An anonymous box is a box without any associated element in the DOM tree and which is generated for layout purpose only. The properties of anonymous boxes are inherited from the enclosing non-anonymous box while non-inherited properties have their initial value. An anonymous <mrow> box is an anonymous box with display equal to block math and which is laid out as described in section 3.3.1.2 Layout of <mrow>.

If a MathML element generates an anonymous <mrow> box then it wraps its children in an anonymous <mrow> box. I.e., its subtree in the visual formatting model is made of an anonymous <mrow> box which itself contains the boxes associated to the children of this MathML element.

In the following example, the math and mrow elements are laid out as described in section 3.3.1.2 Layout of <mrow>. In particular, the <math> element adds proper spacing around its <mo>≠</mo> child and the <mrow> element stretches its <mo>|</mo> children vertically.

The mtd element has display: table-cell and the msqrt element displays a radical symbol around its children. However, they also place their children in a way that is similar to what is described in section 3.3.1.2 Layout of <mrow>: the <msqrt> element adds proper spacing around its <mo>+</mo> child while the <mtd> element stretches its <mo> children vertically. In order to make this possible, each of these two elements generates an anonymous <mrow> box.

<math> <mrow> <mo>|</mo> <mtable> <mtr> <mtd> <mi>x</mi> </mtd> <mtd> <mo>(</mo> <mfrac linethickness="0"> <mn>5</mn> <mn>3</mn> </mfrac> <mo>)</mo> </mtd> </mtr> <mtr> <mtd> <msqrt> <mn>7</mn> <mo>+</mo> <mn>2</mn> </msqrt> </mtd> <mtd> <mi>y</mi> </mtd> </mtr> </mtable> <mo>|</mo> </mrow> <mo>≠</mo> <mn>0</mn> </math>

MathML elements can overlap due to various spacing rules. They can as well contain extra graphical items (bars, radical symbol, etc). A MathML element with computed style display: block math or display: inline math generates a new stacking context. The painting order of in-flow children of such a MathML element is exactly the same as block elements. The extra graphical items are painted after text and background (right after step 7.2.4 for display: inline math and right after step 7.2 for display: block math).

The mtext element is used to represent arbitrary text that should be rendered as itself. In general, the <mtext> element is intended to denote commentary text.

The <mtext> element accepts the attributes described in 2.1.3 Global Attributes.

In the following example, mtext is used to put conditional words in a definition:

<math> <mi>y</mi> <mo>=</mo> <mrow> <msup> <mi>x</mi> <mn>2</mn> </msup> <mtext>&nbsp;if&nbsp;</mtext> <mrow> <mi>x</mi> <mo>≥</mo> <mn>1</mn> </mrow> <mtext>&nbsp;and&nbsp;</mtext> <mn>2</mn> <mtext>&nbsp;otherwise.</mtext> </mrow> </math>

The mi element represents a symbolic name or arbitrary text that should be rendered as an identifier. Identifiers can include variables, function names, and symbolic constants.

The <mi> element accepts the attributes described in 2.1.3 Global Attributes as well as the following attribute:

• mathvariant

The layout algorithm is the same as the mtext element. The user agent stylesheet must contain the following property in order to implement automatic italic via the text-transform value introduced in 4.2 The math-auto transform:

mi { text-transform: math-auto; }

The mathvariant attribute, if present, must be an ASCII case-insensitive match of normal. In that case, the user agent is expected to treat the attribute as a presentational hint setting the element's text-transform property to none. Otherwise it has no effects.

In the following example, mi is used to render variables and function names. Note that per 4.2 The math-auto transform the default style text-transform: math-auto has no effect on the first <mi> ("cos" is made of three characters), makes the second <mi> render as math italic ("c" is made of a single character U+0063 Latin Small Letter C which is mapped to U+1D450 Mathematical Italic Small C per the italic table), has no effect on the third <mi> (overridden by mathvariant="normal", setting text-transform to none) or on the fourth <mi> (no mapping defined for U+221E Infinity in the italic table).

<math> <mi>cos</mi> <mo>,</mo> <mi>c</mi> <mo>,</mo> <mi mathvariant="normal">c</mi> <mo>,</mo> <mi>∞</mi> </math>

The mn element represents a "numeric literal" or other data that should be rendered as a numeric literal. Generally speaking, a numeric literal is a sequence of digits, perhaps including a decimal point, representing an unsigned integer or real number.

The <mn> element accepts the attributes described in 2.1.3 Global Attributes. Its layout algorithm is the same as the mtext element.

In the following example, mn is used to write a decimal number.

<math> <mn>3.141592653589793</mn> </math>

The mo element represents an operator or anything that should be rendered as an operator. In general, the notational conventions for mathematical operators are quite complicated, and therefore MathML provides a relatively sophisticated mechanism for specifying the rendering behavior of an <mo> element.

As a consequence, in MathML the list of things that should "render as an operator" includes a number of notations that are not mathematical operators in the ordinary sense. Besides ordinary operators with infix, prefix, or postfix forms, these include fence characters such as braces, parentheses, and "absolute value" bars; separators such as comma and semicolon; and mathematical accents such as a bar or tilde over a symbol. This chapter uses the term "operator" to refer to operators in this broad sense.

The <mo> element accepts the attributes described in 2.1.3 Global Attributes as well as the following attributes:

• form
• fence
• separator
• lspace
• rspace
• stretchy
• symmetric
• maxsize
• minsize
• largeop
• movablelimits

This specification does not define any observable behavior that is specific to the fence and separator attributes.

In the following example, the mo element is used for the binary operator +. Default spacing is symmetric around that operator. A tighter spacing is used if you rely on the form attribute to force it to be treated as a prefix operator. Spacing can also be specified explicitly using the lspace and rspace attributes.

<math> <mn>1</mn> <mo>+</mo> <mn>2</mn> <mo form="prefix">+</mo> <mn>3</mn> <mo lspace="2em">+</mo> <mn>4</mn> <mo rspace="3em">+</mo> <mn>5</mn> </math>

Another use case is for big operators such as summation. When displaystyle is true, such an operator is drawn larger but one can change that with the largeop attribute. When displaystyle is false, underscripts are actually rendered as subscripts but one can change that with the movablelimits attribute.

<math> <mrow displaystyle="true"> <munder> <mo>∑</mo> <mn>5</mn> </munder> <munder> <mo largeop="false">∑</mo> <mn>6</mn> </munder> </mrow> <mrow> <munder> <mo>∑</mo> <mn>5</mn> </munder> <munder> <mo movablelimits="false">∑</mo> <mn>7</mn> </munder> </mrow> </math>

Operators are also used for stretchy symbols such as fences, accents, arrows etc. In the following example, the vertical arrow stretches to the height of the mspace element. One can override default stretch behavior with the stretchy attribute e.g. to force an unstretched arrow. The symmetric attribute allows to indicate whether the operator should stretch symmetrically above and below the math axis (fraction bar). Finally the minsize and maxsize attributes add additional constraints over the stretch size.

<math> <mfrac> <mspace height="50px" depth="50px" width="10px" style="background: blue"/> <mspace height="25px" depth="25px" width="10px" style="background: green"/> </mfrac> <mo>↑</mo> <mo stretchy="false">↑</mo> <mo symmetric="true">↑</mo> <mo minsize="250px">↑</mo> <mo maxsize="50px">↑</mo> </math>

Note that the default properties of operators are dictionary-based, as explained in 3.2.4.2 Dictionary-based attributes. For example a binary operator typically has default symmetric spacing around it while a fence is generally stretchy by default.

The mspace empty element represents a blank space of any desired size, as set by its attributes.

The <mspace> element accepts the attributes described in 2.1.3 Global Attributes as well as the following attributes:

• width
• height
• depth

The width, height, depth, if present, must have a value that is a valid <length-percentage>.

• If the width attribute is present, valid and not a percentage then that attribute is used as a presentational hint setting the element's width property to the corresponding value.
• If the height attribute is absent, invalid or a percentage then the requested line-ascent is 0. Otherwise the requested line-ascent is the resolved value of the height attribute, clamping negative values to 0.
• If both the height and depth attributes are present, valid and not a percentage then they are used as a presentational hint setting the element's height property to the concatenation of the strings "calc(", the height attribute value, " + ", the depth attribute value, and ")". If only one of these attributes is present, valid and not a percentage then it is treated as a presentational hint setting the element's height property to the corresponding value.

In the following example, mspace is used to force spacing within the formula (a 1px blue border is added to easily visualize the space):

<math> <mn>1</mn> <mspace width="1em" style="border-top: 1px solid blue"/> <mfrac> <mrow> <mn>2</mn> <mspace depth="1em" style="border-left: 1px solid blue"/> </mrow> <mrow> <mn>3</mn> <mspace height="2em" style="border-left: 1px solid blue"/> </mrow> </mfrac> </math>

If the <mspace> element does not have its computed display property equal to block math or inline math then it is laid out according to the CSS specification where the corresponding value is described. Otherwise, the <mspace> element is laid out as shown on Figure 9. The min-content inline size, max-content inline size and inline size of the math content are equal to the resolved value of the width property. The block size of the math content is equal to the resolved value of the height property. The line-ascent of the math content is equal to the requested line-ascent determined above.

ms element is used to represent "string literals" in expressions meant to be interpreted by computer algebra systems or other systems containing "programming languages".

The <ms> element accepts the attributes described in 2.1.3 Global Attributes. Its layout algorithm is the same as the mtext element.

In the following example, ms is used to write a literal string of characters:

<math> <mi>s</mi> <mo>=</mo> <ms>"hello world"</ms> </math>

ms:before, ms:after { content: "\0022"; } ms[lquote]:before { content: attr(lquote); } ms[rquote]:after { content: attr(rquote); }

The mrow element is used to group together any number of sub-expressions, usually consisting of one or more <mo> elements acting as "operators" on one or more other expressions that are their "operands".

In the following example, mrow is used to group a sum "1 + 2/3" as a fraction numerator (first child of mfrac) and to construct a fenced expression (first child of msup) that is raised to the power of 5. Note that mrow alone does not add visual fences around its grouped content, one has to explicitly specify them using the mo element.

Within the mrow elements, one can see that vertical alignment of children (according to the alphabetic baseline or the mathematical baseline) is properly performed, fences are vertically stretched and spacing around the binary + operator automatically calculated.

<math> <msup> <mrow> <mo>(</mo> <mfrac> <mrow> <mn>1</mn> <mo>+</mo> <mfrac> <mn>2</mn> <mn>3</mn> </mfrac> </mrow> <mn>4</mn> </mfrac> <mo>)</mo> </mrow> <mn>5</mn> </msup> </math>

The <mrow> element accepts the attributes described in 2.1.3 Global Attributes. An <mrow> element with in-flow children child₁, child₂, …, child_N is laid out as shown on Figure 10. The child boxes are put in a row one after the other with all their alphabetic baselines aligned.

3.3.1.1 Algorithm for stretching operators along the block axis

The algorithm for stretching operators along the block axis consists in the following steps:

1. If there is a block stretch size constraint or an inline stretch size constraint then the element being laid out is an embellished operator. Lay out the one in-flow child that is an embellished operator with the same stretch size constraint and all the other in-flow children without any stretch size constraint and stop.
2. Otherwise, split the list of in-flow children into a first list LToStretch containing embellished operators with a stretchy property and block stretch axis; and a second list LNotToStretch.
3. Perform layout without any stretch size constraint on all the items of LNotToStretch. If LToStretch is empty then stop. If LNotToStretch is empty, perform layout with block stretch size constraint (0, 0) for all the items of LToStretch.
4. Calculate the unconstrained target sizes Uascent and Udescent as respectively the maximum ink ascent and maximum ink descent of the margin boxes of in-flow children that have been laid out in the previous step.
5. Lay out or relayout all the elements of LToStretch with block stretch size constraint (Uascent, Udescent).

The mfrac element is used for fractions. It can also be used to mark up fraction-like objects such as binomial coefficients and Legendre symbols.

If the <mfrac> element does not have its computed display property equal to block math or inline math then it is laid out according to the CSS specification where the corresponding value is described. Otherwise, the layout below is performed.

The <mfrac> element accepts the attributes described in 2.1.3 Global Attributes as well as the following attribute:

• linethickness

The linethickness attribute indicates the fraction line thickness to use for the fraction bar. If present, it must have a value that is a valid <length-percentage>. If the attribute is absent or has an invalid value, FractionRuleThickness is used as the default value. A percentage is interpreted relative to that default value. A negative value is interpreted as 0.

The following example contains four fractions with different linethickness values. The bars are always aligned with the middle of plus and minus signs. The numerator and denominator are horizontally centered. The fractions that are not in displaystyle use smaller gaps and font-size.

<math> <mn>0</mn> <mo>+</mo> <mfrac displaystyle="true"> <mn>1</mn> <mn>2</mn> </mfrac> <mo>−</mo> <mfrac> <mn>1</mn> <mn>2</mn> </mfrac> <mo>+</mo> <mfrac linethickness="200%"> <mn>1</mn> <mn>234</mn> </mfrac> <mo>−</mo> <mrow> <mo>(</mo> <mfrac linethickness="0"> <mn>123</mn> <mn>4</mn> </mfrac> <mo>)</mo> </mrow> </math>

The <mfrac> element sets displaystyle to false, or if it was already false increments scriptlevel by 1, within its children. It sets math-shift to compact within its second child. To avoid visual confusion between the fraction bar and another adjacent items (e.g. minus sign or another fraction's bar), a default 1-pixel space is added around the element. The user agent stylesheet must contain the following rules:

mfrac { padding-inline: 1px; } mfrac > * { math-depth: auto-add; math-style: compact; } mfrac > :nth-child(2) { math-shift: compact; }

If the <mfrac> element has less or more than two in-flow children, its layout algorithm is the same as the mrow element. Otherwise, the first in-flow child is called numerator, the second in-flow child is called denominator and the layout algorithm is explained below.

3.3.2.1 Fraction with nonzero line thickness

If the fraction line thickness is nonzero, the <mfrac> element is laid out as shown on Figure 12. The fraction bar must only be painted if the visibility of the <mfrac> element is visible. In that case, the fraction bar must be painted with the color of the <mfrac> element.

The min-content inline size (respectively max-content inline size) of content is the maximum between the min-content inline size (respectively max-content inline size) of the numerator's margin box and the min-content inline size (respectively max-content inline size) of the denominator's margin box.

If there is an inline stretch size constraint or a block stretch size constraint then the numerator is also laid out with the same stretch size constraint, otherwise it is laid out without any stretch size constraint. The denominator is always laid out without any stretch size constraint.

The inline size of the math content is the maximum between the inline size of the numerator's margin box and the inline size of the denominator's margin box.

NumeratorShift is the maximum between:

• FractionNumeratorShiftUp (respectively FractionNumeratorDisplayStyleShiftUp) if the math-style is compact (respectively normal).
• The AxisHeight + half the fraction line thickness + FractionNumeratorGapMin (respectively FractionNumDisplayStyleGapMin) if the math-style is compact (respectively normal) + the ink line-descent of the numerator's margin box.

DenominatorShift is the maximum between:

• FractionDenominatorShiftDown (respectively FractionDenominatorDisplayStyleShiftDown) if the math-style is compact (respectively normal).
• Half the fraction line thickness + FractionDenominatorGapMin (respectively FractionDenomDisplayStyleGapMin) if the math-style is compact (respectively normal) + the ink line-ascent of the denominator's margin box − the AxisHeight.

The line-ascent of the math content is the maximum between:

• Numerator Shift + the line-ascent of the numerator's margin box.
• −Denominator Shift + the line-ascent of the denominator's margin box
• AxisHeight plus half the fraction line thickness.

The line-descent of the math content is the maximum between:

• −Numerator Shift + the line-descent of the numerator's margin box.
• Denominator Shift + the line-descent of the denominator's margin box.
• −AxisHeight plus half the fraction line thickness.
• 0

The inline offset of the numerator (respectively denominator) is half the inline size of the math content − half the inline size of the numerator's margin box (respectively denominator's margin box).

The alphabetic baseline of the numerator (respectively denominator) is shifted away from the alphabetic baseline by a distance of NumeratorShift (respectively DenominatorShift) towards the line-over (respectively line-under).

The math content box is placed within the content box so that their block-start edges are aligned and the middles of these edges are at the same position.

The inline size of the fraction bar is the inline size of the content box and its inline-start edge is the aligned with the one the content box. The center of the fraction bar is shifted away from the alphabetic baseline of the math content box by a distance of AxisHeight towards the line-over. Its block size is the fraction line thickness.

3.3.2.2 Fraction with zero line thickness

If the fraction line thickness is zero, the <mfrac> element is instead laid out as shown on Figure 13.

The min-content inline size, max-content inline size and inline size of the math content are calculated the same as in 3.3.2.1 Fraction with nonzero line thickness.

If there is an inline stretch size constraint or a block stretch size constraint then the numerator is also laid out with the same stretch size constraint and otherwise it is laid out without any stretch size constraint. The denominator is always laid out without any stretch size constraint.

If the math-style is compact then TopShift and BottomShift are respectively set to StackTopShiftUp and StackBottomShiftDown. Otherwise math-style is normal and they are respectively set to StackTopDisplayStyleShiftUp and StackBottomDisplayStyleShiftDown.

The Gap is defined to be (BottomShift − the ink line-ascent of the denominator's margin box) + (TopShift − the ink line-descent of the numerator's margin box). If math-style is compact then GapMin is StackGapMin, otherwise math-style is normal and it is StackDisplayStyleGapMin. If Δ = GapMin − Gap is positive then TopShift and BottomShift are respectively increased by Δ/2 and Δ − Δ/2.

The line-ascent of the math content is the maximum between:

• TopShift + the line-ascent of the numerator's margin box.
• −BottomShift + the line-ascent of the denominator's margin box.

The line-descent of the math content is the maximum between:

• −TopShift + the line-descent of the numerator's margin box.
• BottomShift + the line-descent of the denominator's margin box.
• 0

The inline offsets of the numerator and denominator are calculated the same as in 3.3.2.1 Fraction with nonzero line thickness.

The alphabetic baseline of the numerator (respectively denominator) is shifted away from the alphabetic baseline by a distance of TopShift (respectively − BottomShift) towards the line-over (respectively line-under).

The math content box is placed within the content box so that their block-start edges are aligned and the middles of these edges are at the same position.

The radical elements construct an expression with a root symbol √ with a line over the content. The msqrt element is used for square roots, while the mroot element is used to draw radicals with indices, e.g. a cube root.

The <msqrt> and <mroot> elements accept the attributes described in 2.1.3 Global Attributes.

The following example contains a square root written with msqrt and a cube root written with mroot. Note that msqrt has several children and the square root applies to all of them. mroot has exactly two children: it is a root of index the second child (the number 3), applied to the first child (the square root). Also note these elements only change the font-size within the mroot index, but it is scaled down more than within the numerator and denumerator of the fraction.

<math> <mroot> <msqrt> <mfrac> <mn>1</mn> <mn>2</mn> </mfrac> <mo>+</mo> <mn>4</mn> </msqrt> <mn>3</mn> </mroot> <mo>+</mo> <mn>0</mn> </math>

The <msqrt> and <mroot> elements sets math-shift to compact. The <mroot> element increments scriptlevel by 2, and sets displaystyle to "false" in all but its first child. The user agent stylesheet must contain the following rule in order to implement that behavior:

mroot > :not(:first-child) { math-depth: add(2); math-style: compact; } mroot, msqrt { math-shift: compact; }

If the <msqrt> or <mroot> element do not have their computed display property equal to block math or inline math then they are laid out according to the CSS specification where the corresponding value is described. Otherwise, the layout below is performed.

If the <mroot> has less or more than two in-flow children, its layout algorithm is the same as the mrow element. Otherwise, the first in-flow child is called mroot base and the second in-flow child is called mroot index and its layout algorithm is explained below.

The <msqrt> element generates an anonymous <mrow> box called the msqrt base.

3.3.3.2 Square root

The <msqrt> element is laid out as shown on Figure 14.

The min-content inline size (respectively max-content inline size) of the math content is the sum of the preferred inline size of a glyph stretched along the block axis for the radical glyph and of the min-content inline size (respectively max-content inline size) of the msqrt base's margin box.

The inline size of the math content is the sum of the advance width of the box metrics of the radical glyph and of the inline size of the msqrt base's margin's box.

The line-ascent of the math content is the maximum between:

• The line-ascent of the msqrt base's margin box.
• The sum of the ink line-ascent of the msqrt base, the radical gap, the RadicalRuleThickness and RadicalExtraAscender.

The line-descent of the math content is the maximum between:

• The line-descent of the msqrt base's margin box.
• The sum of the line-ascent and line-descent for the box metrics of the radical glyph and of the RadicalExtraAscender, minus the line-ascent of the math content.

The inline size of the overbar is the inline size of the msqrt base's margin's box. The inline offsets of the msqrt base and overbar are also the same and equal to the width of the box metrics of the radical glyph.

The alphabetic baseline of the msqrt base is aligned with the alphabetic baseline. The block size of the overbar is RadicalRuleThickness. Its vertical center is shifted away from the alphabetic baseline by a distance towards the line-over equal to the line-ascent of the math content, minus the RadicalExtraAscender, minus half the RadicalRuleThickness.

Finally, the painting of the surd is performed:

• At inline offset 0.
• At block offset shifted away from the line-over edge of the overbar towards the line-under by a distance given by the ascent of the box metrics of the radical glyph.

3.3.3.3 Root with index

The <mroot> element is laid out as shown on Figure 15. The mroot index is first ignored and the mroot base and radical glyph are laid out as shown on figure Figure 14 using the same algorithm as in 3.3.3.2 Square root in order to produce a margin box B (represented in green).

The min-content inline size (respectively max-content inline size) of the math content is the sum of max(0, RadicalKernBeforeDegree), the mroot index's min-content inline size (respectively max-content inline size) of the mroot index's margin box, max(−min-content inline size, RadicalKernAfterDegree) (respectively max(−max-content inline size of the mroot index's margin box, RadicalKernAfterDegree)) and of the min-content inline size (respectively max-content inline size) of B.

Using the same clamping, AdjustedRadicalKernBeforeDegree and AdjustedRadicalKernAfterDegree are respectively defined as max(0, RadicalKernBeforeDegree) and is max(−inline size of the index's margin box, RadicalKernAfterDegree).

The inline size of the math content is the sum of AdjustedRadicalKernBeforeDegree, the inline size of the index's margin box, AdjustedRadicalKernAfterDegree and of the inline size of B.

The line-ascent of the math content is the maximum between:

• −the line-descent of B + RadicalDegreeBottomRaisePercent × the block size of B + the line-ascent of the index's margin box
• The line-ascent of B

The line-descent of the math content is the maximum between:

• the line-descent of B − RadicalDegreeBottomRaisePercent × the block size of B + the line-ascent of the index's margin box
• The line-descent of B

The inline offset of the index is AdjustedRadicalKernBeforeDegree. The inline-offset of the mroot base is the same + the inline size of the index's margin box.

The alphabetic baseline of B is aligned with the alphabetic baseline. The alphabetic baseline of the index is shifted away from the line-under edge by a distance of RadicalDegreeBottomRaisePercent × the block size of B + the line-descent of the index's margin box.

Note

In general, the kerning before the root index is positive while the kerning after it is negative, which means that the root element will have some inline-start space and that the root index will overlap the surd.

Historically, the mstyle element was introduced to make style changes that affect the rendering of its contents.

The <mstyle> element accepts the attributes described in 2.1.3 Global Attributes. Its layout algorithm is the same as the mrow element.

In the following example, mstyle is used to set the scriptlevel and displaystyle. Observe this is respectively affecting the font-size and placement of subscripts of their descendants. In MathML Core, one could just have used mrow elements instead.

<math> <munder> <mo movablelimits="true">*</mo> <mi>A</mi> </munder> <mstyle scriptlevel="1"> <mstyle displaystyle="true"> <munder> <mo movablelimits="true">*</mo> <mi>B</mi> </munder> <munder> <mo movablelimits="true">*</mo> <mi>C</mi> </munder> </mstyle> <munder> <mo movablelimits="true">*</mo> <mi>D</mi> </munder> </mstyle> </math>

The merror element displays its contents as an ”error message”. The intent of this element is to provide a standard way for programs that generate MathML from other input to report syntax errors in their input.

In the following example, merror is used to indicate a parsing error for some LaTeX-like input:

<math> <mfrac> <merror> <mtext>Syntax error: \frac{1}</mtext> </merror> <mn>3</mn> </mfrac> </math>

The <merror> element accepts the attributes described in 2.1.3 Global Attributes. Its layout algorithm is the same as the mrow element. The user agent stylesheet must contain the following rule in order to visually highlight the error message:

merror { border: 1px solid red; background-color: lightYellow; }

The mpadded element renders the same as its in-flow child content, but with the size and relative positioning point of its content modified according to <mpadded>’s attributes.

The <mpadded> element accepts the attributes described in 2.1.3 Global Attributes as well as the following attributes:

• width
• height
• depth
• lspace
• voffset

The width, height, depth, lspace and voffset if present, must have a value that is a valid <length-percentage>.

In the following example, mpadded is used to tweak spacing around a fraction (a blue background is used to visualize it). Without attributes, it behaves like an mrow but the attributes allow to specify the size of the box (width, height, depth) and position of the fraction within that box (lspace and voffset).

<math> <mrow> <mn>1</mn> <mpadded style="background: lightblue;"> <mfrac> <mn>23456</mn> <mn>78</mn> </mfrac> </mpadded> <mn>9</mn> </mrow> <mo>+</mo> <mrow> <mn>1</mn> <mpadded lspace="2em" voffset="-1em" height="1em" depth="3em" width="7em" style="background: lightblue;"> <mfrac> <mn>23456</mn> <mn>78</mn> </mfrac> </mpadded> <mn>9</mn> </mrow> </math>

3.3.6.2 Layout of <mpadded>

If the <mpadded> element does not have its computed display property equal to block math or inline math then it is laid out according to the CSS specification where the corresponding value is described. Otherwise, it is laid out as shown on Figure 16.

The min-content inline size (respectively max-content inline size) of the math content is the requested width calculated in 3.3.6.1 Inner box and requested parameters but using the min-content inline size (respectively max-content inline size) of the mpadded inner box instead of the "inner inline size".

The inline size of the math content is the requested width calculated in 3.3.6.1 Inner box and requested parameters.

The line-ascent of the math content is the requested height. The line-descent of the math content is the requested depth.

The mpadded inner box is placed so that its alphabetic baseline is shifted away from the alphabetic baseline by the requested voffset towards the line-over.

Historically, the mphantom element was introduced to render its content invisibly, but with the same metrics size and other dimensions, including alphabetic baseline position that its contents would have if they were rendered normally.

In the following example, mphantom is used to ensure alignment of corresponding parts of the numerator and denominator of a fraction:

<math> <mfrac> <mrow> <mi>x</mi> <mo>+</mo> <mi>y</mi> <mo>+</mo> <mi>z</mi> </mrow> <mrow> <mi>x</mi> <mphantom> <mo form="infix">+</mo> <mi>y</mi> </mphantom> <mo>+</mo> <mi>z</mi> </mrow> </mfrac> </math>

The <mphantom> element accepts the attributes described in 2.1.3 Global Attributes. Its layout algorithm is the same as the mrow element. The user agent stylesheet must contain the following rule in order to hide the content:

mphantom { visibility: hidden; }

The msub, msup and msubsup elements are used to attach subscript and superscript to a MathML expression. They accept the attributes described in 2.1.3 Global Attributes.

The following example shows basic use of subscripts and superscripts. The font-size is automatically scaled down within the scripts.

<math> <msub> <mn>1</mn> <mn>2</mn> </msub> <mo>+</mo> <msup> <mn>3</mn> <mn>4</mn> </msup> <mo>+</mo> <msubsup> <mn>5</mn> <mn>6</mn> <mn>7</mn> </msubsup> </math>

If the <msub>, <msup> or <msubsup> elements do not have their computed display property equal to block math or inline math then they are laid out according to the CSS specification where the corresponding value is described. Otherwise, the layout below is performed.

3.4.1.2 Base with subscript

The <msub> element is laid out as shown on Figure 17. LargeOpItalicCorrection is the italic correction of the msub base if it is an embellished operator with the largeop property and 0 otherwise.

The min-content inline size (respectively max-content inline size) of the math content is the min-content inline size (respectively max-content inline size) of the msub base's margin box − LargeOpItalicCorrection + min-content inline size (respectively max-content inline size) of the msub subscript's margin box + SpaceAfterScript.

If there is an inline stretch size constraint or a block stretch size constraint then the msub base is also laid out with the same stretch size constraint and otherwise it is laid out without any stretch size constraint. The scripts are always laid out without any stretch size constraint.

The inline size of the math content is the inline size of the msub base's margin box − LargeOpItalicCorrection + the inline size of the msub subscript's margin box + SpaceAfterScript.

SubShift is the maximum between:

• SubscriptShiftDown
• the ink line-ascent of the subscript's margin box − SubscriptTopMax
• SubscriptBaselineDropMin + the ink line-descent of the msub base's margin box

The line-ascent of the math content is the maximum between:

• The line-ascent of the msub base's margin box.
• The line-ascent of the subscript's margin box − SubShift.

The line-descent of the math content is the maximum between:

• The line-descent of the msub base's margin box.
• The line-descent of the subscript's margin box + SubShift.

The inline offset of the msub base is 0 and the inline offset of the msub subscript is the inline size of the msub base's margin box − LargeOpItalicCorrection.

The msub base is placed so that its alphabetic baseline matches the alphabetic baseline. The msub subscript is placed so that its alphabetic baseline is shifted away from the alphabetic baseline by SubShift towards the line-under.

3.4.1.3 Base with superscript

The <msup> element is laid out as shown on Figure 18. ItalicCorrection is the italic correction of the msup base if it is not an embellished operator with the largeop property and 0 otherwise.

The min-content inline size (respectively max-content inline size) of the math content is the min-content inline size (respectively max-content inline size) of the msup base's margin box + ItalicCorrection + the min-content inline size (respectively max-content inline size) of the msup superscript's margin box + SpaceAfterScript.

If there is an inline stretch size constraint or a block stretch size constraint then the msup base is also laid out with the same stretch size constraint and otherwise it is laid out without any stretch size constraint. The scripts are always laid out without any stretch size constraint.

The inline size of the math content is the inline size of the msup base's margin box + ItalicCorrection + the inline size of the msup superscript's margin box + SpaceAfterScript.

SuperShift is the maximum between:

• The value SuperscriptShiftUpCramped if the element has a computed math-shift property equal to compact, or SuperscriptShiftUp otherwise.
• SuperscriptBottomMin + the ink line-descent of the superscript's margin box
• The ink line-ascent of the msup base's margin box − SuperscriptBaselineDropMax

The line-ascent of the math content is the maximum between:

• The line-ascent of the msup base's margin box.
• The line-ascent of the superscript's margin box + SuperShift.

The line-descent of the math content is the maximum between:

• The line-descent of the msup base's margin box.
• The line-descent of the superscript's margin box − SuperShift.

The inline offset of the msup base is 0 and the inline offset of msup superscript is the inline size of the msup base's margin box + ItalicCorrection.

The msup base is placed so that its alphabetic baseline matches the alphabetic baseline. The msup superscript is placed so that its alphabetic baseline is shifted away from the alphabetic baseline by SuperShift towards the line-over.

3.4.1.4 Base with subscript and superscript

The <msubsup> element is laid out as shown on Figure 18. LargeOpItalicCorrection and SubShift are set as in 3.4.1.2 Base with subscript. ItalicCorrection and SuperShift are set as in 3.4.1.3 Base with superscript.

The min-content inline size (respectively max-content inline size and inline size) of the math content is the maximum between the min-content inline size (respectively max-content inline size and inline size) of the math content calculated in 3.4.1.2 Base with subscript and 3.4.1.3 Base with superscript.

If there is an inline stretch size constraint or a block stretch size constraint then the msubsup base is also laid out with the same stretch size constraint and otherwise it is laid out without any stretch size constraint. The scripts are always laid out without any stretch size constraint.

If there is an inline stretch size constraint or a block stretch size constraint then the msubsup base is also laid out with the same stretch size constraint and otherwise it is laid out without any stretch size constraint. The scripts are always laid out without any stretch size constraint.

SubSuperGap is the gap between the two scripts along the block axis and is defined by (SubShift − the ink line-ascent of the msubsup subscript's margin box) + (SuperShift − the ink line-descent of the msubsup superscript's margin box). If SubSuperGap is not at least SubSuperscriptGapMin then the following steps are performed to ensure that the condition holds:

1. Let Δ be SuperscriptBottomMaxWithSubscript − (SuperShift − the ink line-descent of the msubsup superscript's margin box). If Δ > 0 then set Δ to the minimum between Δ set SubSuperscriptGapMin − SubSuperGap and increase SuperShift (and so SubSuperGap too) by Δ.
2. Let Δ be SubSuperscriptGapMin − SubSuperGap. If Δ > 0 then increase SubscriptShift (and so SubSuperGap too) by Δ.

The ink line-ascent (respectively line-ascent, ink line-descent, line-descent) of the math content is set to the maximum of the ink line-ascent (respectively line-ascent, ink line-descent, line-descent) of the math content calculated in 3.4.1.2 Base with subscript and 3.4.1.3 Base with superscript but using the adjusted values SubShift and SuperShift above.

The inline offset and block offset of the msubsup base and scripts are performed the same as described in 3.4.1.2 Base with subscript and 3.4.1.3 Base with superscript.

Note

Even when the msubsup subscript (respectively msubsup superscript) is an empty box, <msubsup> does not generally render the same as 3.4.1.3 Base with superscript (respectively 3.4.1.2 Base with subscript) because of the additional constraint on SubSuperGap. Moreover, positioning the empty msubsup subscript (respectively msubsup superscript) may also change the total size.

In order to keep the algorithm simple, no attempt is made to handle empty scripts in a special way.

The munder, mover and munderover elements are used to attach accents or limits placed under or over a MathML expression.

The <munderover> element accepts the attribute described in 2.1.3 Global Attributes as well as the following attributes:

• accent
• accentunder

Similarly, the <mover> element (respectively <munder> element) accepts the attribute described in 2.1.3 Global Attributes as well as the accent attribute (respectively the accentunder attribute).

accent, accentunder attributes, if present, must have values that are booleans. If these attributes are absent or invalid, they are treated as equal to false. User agents must implement them as described in 3.4.4 Displaystyle, scriptlevel and math-shift in scripts.

The following example shows basic use of under- and overscripts. The font-size is automatically scaled down within the scripts, unless they are meant to be accents.

<math> <munder> <mn>1</mn> <mn>2</mn> </munder> <mo>+</mo> <mover> <mn>3</mn> <mn>4</mn> </mover> <mo>+</mo> <munderover> <mn>5</mn> <mn>6</mn> <mn>7</mn> </munderover> <mo>+</mo> <munderover accent="true"> <mn>8</mn> <mn>9</mn> <mn>10</mn> </munderover> <mo>+</mo> <munderover accentunder="true"> <mn>11</mn> <mn>12</mn> <mn>13</mn> </munderover> </math>

If the <munder>, <mover> or <munderover> elements do not have their computed display property equal to block math or inline math then they are laid out according to the CSS specification where the corresponding value is described. Otherwise, the layout below is performed.

3.4.2.3 Base with underscript

The <munder> element is laid out as shown on Figure 20. LargeOpItalicCorrection is the italic correction of the munder base if it is an embellished operator with the largeop property and 0 otherwise.

The min-content inline size (respectively max-content inline size) of the math content are calculated like the inline size of the math content below but replacing the inline sizes of the munder base's margin box and munder underscript's margin box with the min-content inline size (respectively max-content inline size) of the munder base's margin box and munder underscript's margin box.

The in-flow children are laid out using the algorithm for stretching operators along the inline axis.

The inline size of the math content is calculated by determining the absolute difference between:

• The maximum of:
  • Half the inline size of the munder base's margin box.
  • Half the inline size of the munder underscript's margin box − half LargeOpItalicCorrection.
• The minimum of:
  • −half the inline size of the munder base's margin box.
  • −half the inline size of the munder underscript's margin box − half LargeOpItalicCorrection.

If m is the minimum calculated in the second item above then the inline offset of the munder base is −m − half the inline size of the base's margin box. The inline offset of the munder underscript is −m − half the inline size of the munder underscript's margin box − half LargeOpItalicCorrection.

Parameters UnderShift and UnderExtraDescender are determined by considering three cases in the following order:

1. The munder base is an embellished operator with the largeop property. UnderShift is the maximum of

   • LowerLimitBaselineDropMin
   • LowerLimitGapMin + the ascent of the munder underscript.

   UnderExtraDescender is 0.

2. The munder base is an embellished operator with the stretchy property and stretch axis inline. UnderShift is the maximum of:

   • StretchStackBottomShiftDown
   • StretchStackGapAboveMin + the ascent of the munder underscript.
   UnderExtraDescender is 0.
3. Otherwise, UnderShift is equal to UnderbarVerticalGap if the accentunder attribute is not an ASCII case-insensitive match to true and to zero otherwise. UnderExtraAscender is UnderbarExtraDescender.

The line-ascent of the math content is the maximum between:

• The line-ascent of the munder base's margin box.
• The line-ascent of the munder underscript's margin box − UnderShift.

The line-descent of the math content is the maximum between:

• The line-descent of the munder base's margin box.
• The line-descent of the munder underscript's margin box + UnderShift + UnderExtraAscender.

The alphabetic baseline of the munder base is aligned with the alphabetic baseline. The alphabetic baseline of the munder underscript is shifted away from the alphabetic baseline and towards the line-under by a distance equal to the ink line-descent of the munder base's margin box + UnderShift.

The math content box is placed within the content box so that their block-start edges are aligned and the middles of these edges are at the same position.

3.4.2.4 Base with overscript

The <mover> element is laid out as shown on Figure 21. LargeOpItalicCorrection is the italic correction of the mover base if it is an embellished operator with the largeop property and 0 otherwise.

The min-content inline size (respectively max-content inline size) of the math content are calculated like the inline size of the math content below but replacing the inline sizes of the mover base's margin box and mover overscript's margin box with the min-content inline size (respectively max-content inline size) of the mover base's margin box and mover overscript's margin box.

The in-flow children are laid out using the algorithm for stretching operators along the inline axis.

The TopAccentAttachment is the top accent attachment of the mover overscript or half the inline size of the mover overscript's margin box if it is undefined.

The inline size of the math content is calculated by applying the algorithm for stretching operators along the inline axis for layout and determining the absolute difference between:

• The maximum of:
  • Half the inline size of the mover base's margin box.
  • The inline size of the mover overscript's margin box − TopAccentAttachment + half LargeOpItalicCorrection.
• The minimum of:
  • −half the inline size of the mover base's margin box.
  • −TopAccentAttachment + half LargeOpItalicCorrection.

If m is the minimum calculated in the second item above then the inline offset of the mover base is −m − half the inline size of the base's margin. The inline offset of the mover overscript is −m − half the inline size of the mover overscript's margin box + half LargeOpItalicCorrection.

Parameters OverShift and OverExtraDescender are determined by considering three cases in the following order:

1. The mover base is an embellished operator with the largeop property. OverShift is the maximum of

   • UpperLimitBaselineRiseMin
   • UpperLimitGapMin + the descent of the mover overscript.

   OverExtraAscender is 0.

2. The mover base is an embellished operator with the stretchy property and stretch axis inline. OverShift is the maximum of:

   • StretchStackTopShiftUp
   • StretchStackGapBelowMin + the descent of the mover overscript.
   OverExtraDescender is 0.

3. Otherwise, OverShift is equal to

   1. OverbarVerticalGap if the accent attribute is not an ASCII case-insensitive match to true.
   2. Or AccentBaseHeight minus the line-ascent of the mover base's margin box if this difference is nonnegative.
   3. Or 0 otherwise.

   OverExtraAscender is OverbarExtraAscender.

Note

For accent overscripts and bases with line-ascents that are at most AccentBaseHeight, the rule from [OPEN-FONT-FORMAT] [TEXBOOK] is actually to align the alphabetic baselines of the overscripts and of the bases. This assumes that accent glyphs are designed in such a way that their ink bottoms are more or less AccentBaseHeight above their alphabetic baselines. Hence, the previous rule will guarantee that all the overscript bottoms are aligned while still avoiding collision with the bases. However, MathML can have arbitrary accent overscripts, so a more general and simpler rule is provided above: Ensure that the bottom of overscript is at least AccentBaseHeight above the alphabetic baseline of the base.

The line-ascent of the math content is the maximum between:

• The line-ascent of the mover base's margin box.
• The line-ascent of the mover overscript's margin box + OverShift + OverExtraAscender.

The line-descent of the math content is the maximum between:

• The line-descent of the mover base's margin box.
• The line-descent of the mover overscript's margin box − OverShift.

The alphabetic baseline of the mover base is aligned with the alphabetic baseline. The alphabetic baseline of the mover overscript is shifted away from the alphabetic baseline and towards the line-over by a distance equal to the ink line-ascent of the base + OverShift.

The math content box is placed within the content box so that their block-start edges are aligned and the middles of these edges are at the same position.

3.4.2.5 Base with underscript and overscript

The general layout of <munderover> is shown on Figure 22. The LargeOpItalicCorrection, UnderShift, UnderExtraDescender, OverShift, OverExtraDescender parameters are calculated the same as in 3.4.2.3 Base with underscript and 3.4.2.4 Base with overscript.

The min-content inline size, max-content inline size and inline size of the math content are calculated as an absolute difference between a maximum inline offset and minimum inline offset. These extrema are calculated by taking the extremum value of the corresponding extrema calculated in 3.4.2.3 Base with underscript and 3.4.2.4 Base with overscript. The inline offsets of the munderover base, munderover underscript and munderover overscript are calculated as in these sections but using the new minimum m (minimum of the corresponding minima).

Like in these sections, the in-flow children are laid out using the algorithm for stretching operators along the inline axis.

The line-ascent and line-descent of the math content are also calculated by taking the extremum value of the extrema calculated in 3.4.2.3 Base with underscript and 3.4.2.4 Base with overscript.

Finally, the alphabetic baselines of the munderover base, munderover underscript and munderover overscript are calculated as in sections 3.4.2.3 Base with underscript and 3.4.2.4 Base with overscript.

The math content box is placed within the content box so that their block-start edges are aligned and the middles of these edges are at the same position.

Note

When the underscript (respectively overscript) is an empty box, the base and overscript (respectively underscript) are laid out similarly to 3.4.2.4 Base with overscript (respectively 3.4.2.3 Base with underscript) but the position of the empty underscript (respectively overscript) may add extra space. In order to keep the algorithm simple, no attempt is made to handle empty scripts in a special way.

Presubscripts and tensor notations are represented by the mmultiscripts element. The mprescripts element is used as a separator between the postscripts and prescripts. These two elements accept the attributes described in 2.1.3 Global Attributes.

The following example shows basic use of prescripts and postscripts, involving a mprescripts. Empty mrow elements are used at positions where no scripts are rendered. The font-size is automatically scaled down within the scripts.

<math> <mmultiscripts> <mn>1</mn> <mn>2</mn> <mn>3</mn> <mrow></mrow> <mn>5</mn> <mprescripts/> <mn>6</mn> <mrow></mrow> <mn>8</mn> <mn>9</mn> </mmultiscripts> </math>

If the <mmultiscripts> or <mprescripts> elements do not have their computed display property equal to block math or inline math then they are laid out according to the CSS specification where the corresponding value is described. Otherwise, the layout below is performed.

The <mprescripts> element is laid out as an mrow element.

A valid <mmultiscripts> element contains the following in-flow children:

• A first in-flow child, called the mmultiscripts base, that is not an mprescripts element.
• Followed by an even number of in-flow children called mmultiscripts postscripts, none of them being a mprescripts element. These scripts form a (possibly empty) list subscript, superscript, subscript, superscript, subscript, superscript, etc. Each consecutive couple of children subscript, superscript is called a subscript/superscript pair.
• Optionally followed by an mprescripts element and an even number of in-flow children called mmultiscripts prescripts, none of them being a mprescripts element. These scripts form a (possibly empty) list of subscript/superscript pair.

If an <mmultiscripts> element is not valid then it is laid out the same as the mrow element. Otherwise the layout algorithm is performed as in 3.4.3.1 Base with prescripts and postscripts.

3.4.3.1 Base with prescripts and postscripts

The <mmultiscripts> element is laid out as shown on Figure 23. For each subscript/superscript pair of mmultiscripts postscripts, the ItalicCorrection LargeOpItalicCorrection are defined as in 3.4.1.2 Base with subscript and 3.4.1.3 Base with superscript.

The min-content inline size (respectively max-content inline size) of the math content is calculated the same as the inline size of the math content below, but replacing "inline size" with "min-content inline size" (respectively "max-content inline size") for the mmultiscripts base's margin box and scripts' margin boxes.

If there is an inline stretch size constraint or a block stretch size constraint the mmultiscripts base is also laid out with the same stretch size constraint. Otherwise it is laid out without any stretch size constraint. The other elements are always laid out without any stretch size constraint.

The inline size of the math content is calculated with the following algorithm:

1. Set inline-offset to 0.

2. For each subscript/superscript pair of mmultiscripts prescripts, increment inline-offset by SpaceAfterScript + the maximum of

   • The inline size of the subscript's margin box.
   • The inline size of the superscript's margin box.
3. Increment inline-offset by the inline size of the mmultiscripts base's margin box and set inline-size to inline-offset.

4. For each subscript/superscript pair of mmultiscripts postscripts, modify inline-size to be at least:

   • x + the inline size of the subscript's margin box + LargeOpItalicCorrection.
   • x + the inline size of the superscript's margin box − ItalicCorrection.

   Increment inline-offset to the maximum of:

   • the inline size of the subscript's margin box.
   • the inline size of the superscript's margin box.

   Increment inline-offset by SpaceAfterScript.

5. Return inline-size.

SubShift (respectively SuperShift) is calculated by taking the maximum of all subshifts (respectively supershifts) of each subscript/superscript pair as described in 3.4.1.4 Base with subscript and superscript.

The line-ascent of the math content is calculated by taking the maximum of all the line-ascent of each subscript/superscript pair as described in 3.4.1.4 Base with subscript and superscript but using the SubShift and SuperShift values calculated above.

The line-descent of the math content is calculated by taking the maximum of all the line-descent of each subscript/superscript pair as described in 3.4.1.4 Base with subscript and superscript but using the SubShift and SuperShift values calculated above.

Finally, the placement of the in-flow children is performed using the following algorithm:

1. Set inline-offset to 0.

2. For each subscript/superscript pair of mmultiscripts prescripts:

   1. Increment inline-offset by SpaceAfterScript.
   2. Set pair-inline-size to the maximum of
      • the inline size of the subscript's margin box.
      • the inline size of the superscript's margin box.
   3. Place the subscript at inline-start position inline-offset + pair-inline-size − the inline size of the subscript's margin box.
   4. Place the superscript at inline-start position inline-offset + pair-inline-size − the inline size of the superscript's margin box.
   5. Place the subscript (respectively superscript) so its alphabetic baseline is shifted away from the alphabetic baseline by SubShift (respectively SuperShift) towards the line-under (respectively line-over).
   6. Increment inline-offset by pair-inline-size.
3. Place the mmultiscripts base and <mprescripts> boxes at inline offsets inline-offset and with their alphabetic baselines aligned with the alphabetic baseline.

4. For each subscript/superscript pair of mmultiscripts postscripts:

   1. Set pair-inline-size to the maximum of
      • the inline size of the subscript's margin box.
      • the inline size of the superscript's margin box.
   2. Place the subscript at inline-start position inline-offset − LargeOpItalicCorrection.
   3. Place the superscript at inline-start position inline-offset + ItalicCorrection.
   4. Place the subscript (superscript) so its alphabetic baseline is shifted away from the alphabetic baseline by SubShift (respectively SuperShift) towards the line-under (respectively line-over).
   5. Increment inline-offset by pair-inline-size.
   6. Increment inline-offset by SpaceAfterScript.

Note

An <mmultiscripts> with only one subscript/superscript pair of mmultiscripts postscripts is laid out the same as a <msubsup> with the same in-flow children. However, as noticed for <msubsup>, if additionally the subscript (respectively superscript) is an empty box then it is not necessarily laid out the same as an <msub> (respectively <msup>) element. In order to keep the algorithm simple, no attempt is made to handle empty scripts in a special way.

For all scripted elements, the rule of thumb is to set displaystyle to false and to increment scriptlevel in all child elements but the first one. However, an mover (respectively munderover) element with an accent attribute that is an ASCII case-insensitive match to true does not increment scriptlevel within its second child (respectively third child). Similarly, mover and munderover elements with an accentunder attribute that is an ASCII case-insensitive match to true do not increment scriptlevel within their second child.

<mmultiscripts> sets math-shift to compact on its children at even position if they are before an mprescripts, and on those at odd position if they are after an mprescripts. The <msub> and <msubsup> elements set math-shift to compact on their second child. mover and munderover elements with an accent attribute that is an ASCII case-insensitive match to true also set math-shift to compact within their first child.

The A. User Agent Stylesheet must contain the following style in order to implement this behavior:

msub > :not(:first-child), msup > :not(:first-child), msubsup > :not(:first-child), mmultiscripts > :not(:first-child), munder > :not(:first-child), mover > :not(:first-child), munderover > :not(:first-child) { math-depth: add(1); math-style: compact; } munder[accentunder="true" i] > :nth-child(2), mover[accent="true" i] > :nth-child(2), munderover[accentunder="true" i] > :nth-child(2), munderover[accent="true" i] > :nth-child(3) { font-size: inherit; } msub > :nth-child(2), msubsup > :nth-child(2), mmultiscripts > :nth-child(even), mmultiscripts > mprescripts ~ :nth-child(odd), mover[accent="true" i] > :first-child, munderover[accent="true" i] > :first-child { math-shift: compact; } mmultiscripts > mprescripts ~ :nth-child(even) { math-shift: inherit; }

The mtable is laid out as an inline-table and sets displaystyle to false. The user agent stylesheet must contain the following rules in order to implement these properties:

mtable { display: inline-table; math-style: compact; }

The mtable element is as a CSS table and the min-content inline size, max-content inline size, inline size, block size, first baseline set and last baseline set sets are determined accordingly. The center of the table is aligned with the math axis.

The <mtable> accepts the attributes described in 2.1.3 Global Attributes.

The mtr is laid out as table-row. The user agent stylesheet must contain the following rules in order to implement that behavior:

mtr { display: table-row; }

The <mtr> accepts the attributes described in 2.1.3 Global Attributes.

The mtd is laid out as a table-cell with content centered in the cell and a default padding. The user agent stylesheet must contain the following rules:

mtd { display: table-cell; /* Centering inside table cells should rely on box alignment properties. See https://github.com/w3c/mathml-core/issues/156 */ text-align: center; padding: 0.5ex 0.4em; }

The <mtd> accepts the attributes described in 2.1.3 Global Attributes as well as the following attributes:

• columnspan
• rowspan

The columnspan (respectively rowspan) attribute has the same syntax and semantics as the colspan (respectively rowspan) attribute on the <td> element from [HTML]. In particular, the parsing of these attributes is handled as described in the algorithm for processing rows, always reading "colspan" as "columnspan".

The <mtd> element generates an anonymous <mrow> box.

This section is based on [OPEN-TYPE-MATH-IN-HARFBUZZ]. For convenience, the following definitions are used:

• o_min is MATH.MathVariant.minConnectorOverlap.
• A GlyphPartRecord is an extender if and only if GlyphPartRecord.partFlags has the fExtender flag set.
• A GlyphAssembly is horizontal if it is obtained from MathVariant.horizGlyphConstructionOffsets. Otherwise it is vertical (and obtained from MathVariant.vertGlyphConstructionOffsets).
• For a given GlyphAssembly table, N_Ext (respectively N_NonExt) is the number of extenders (respectively non-extenders) in GlyphAssembly.partRecords.
• For a given GlyphAssembly table, S_Ext (respectively S_NonExt) is the sum of GlyphPartRecord.fullAdvance for all extenders (respectively non-extenders) in GlyphAssembly.partRecords.
• S_{Ext,NonOverlapping} = S_Ext − o_min N_Ext is the sum of maximum non overlapping parts of extenders.

User agents must treat the GlyphAssembly as invalid if the following conditions are not satisfied:

• N_Ext > 0. Otherwise, the assembly cannot be grown by repeating extenders.
• S_{Ext,NonOverlapping} > 0. Otherwise, the assembly does not grow when joining extenders.
• For each GlyphPartRecord in GlyphAssembly.partRecords, the values of GlyphPartRecord.startConnectorLength and GlyphPartRecord.endConnectorLength must be at least o_min. Otherwise, it is not possible to satisfy the condition of MathVariant.minConnectorOverlap.

In this specification, a glyph assembly is built by repeating each extender r times and using the same overlap value o between each glyph. The number of glyphs in such an assembly is AssemblyGlyphCount(r) = N_NonExt + r N_Ext while the stretch size is AssembySize(o, r) = S_NonExt + r S_Ext − o (AssemblyGlyphCount(r) − 1).

r_min is the minimal number of repetitions needed to obtain an assembly of size at least T, i.e. the minimal r such that AssembySize(o_min, r) ≥ T. It is defined as the maximum between 0 and the ceiling of ((T − S_NonExt + o_min (N_NonExt − 1)) / S_{Ext,NonOverlapping}).

o_{max,theorical} = (AssembySize(0, r_min) − T) / (AssemblyGlyphCount(r_min) − 1) is the theorical overlap obtained by splitting evenly the extra size of an assembly built with null overlap.

o_max is the maximum overlap possible to build an assembly of size at least T by repeating each extender r_min times. If AssemblyGlyphCount(r_min) ≤ 1, then the actual overlap value is irrelevant. Otherwise, o_max is defined to be the minimum of:

• o_{max,theorical}.
• GlyphPartRecord.startConnectorLength for all the entries in GlyphAssembly.partRecords, excluding the last one if it is not an extender.
• GlyphPartRecord.endConnectorLength for all the entries in GlyphAssembly.partRecords, excluding the first one if it is not an extender.

The glyph assembly stretch size for a target size T is AssembySize(o_max, r_min).

The glyph assembly width, glyph assembly ascent and glyph assembly descent are defined as follows:

• If GlyphAssembly is vertical, the width is the maximum advance width of the glyphs of ID GlyphPartRecord.glyphID for all the GlyphPartRecord in GlyphAssembly.partRecords, the ascent is the glyph assembly stretch size for a given target size T and the descent is 0.
• Otherwise, the GlyphAssembly is horizontal, the width is glyph assembly stretch size for a given target size T while the ascent (respectively descent) is the maximum ascent (respectively descent) of the glyphs of ID GlyphPartRecord.glyphID for all the GlyphPartRecord in GlyphAssembly.partRecords.

The glyph assembly height is the sum of the glyph assembly ascent and glyph assembly descent.

The shaping of the glyph assembly is performed with the following algorithm:

1. Calculate r_min and o_max.
2. Set (x, y) to (0, 0), RepetitionCounter to 0 and PartIndex to -1.
3. Repeat the following steps:
   1. If RepetitionCounter is 0:
      1. Increment PartIndex.
      2. If PartIndex is GlyphAssembly.partCount then stop.
      3. Otherwise, set Part to GlyphAssembly.partRecords[PartIndex]. Set RepetitionCounter to r_min if Part is an extender and to 1 otherwise.
   2. • If the glyph assembly is horizontal then draw the glyph of ID Part.glyphID so that its (left, baseline) coordinates are at position (x, y). Set x to x + Part.fullAdvance − omax.
      • Otherwise (if the glyph assembly is vertical), then draw the glyph of id Part.glyphID so that its (left, bottom) coordinates are at position (x, y). Set y to y − Part.fullAdvance + omax.
   3. Decrement RepetitionCounter.

The preferred inline size of a glyph stretched along the block axis is calculated using the following algorithm:

1. Set S to the glyph's advance width.
2. If there is a MathGlyphConstruction table in the MathVariants.vertGlyphConstructionOffsets table for the given glyph:
   1. For each MathGlyphVariantRecord in MathGlyphConstruction.mathGlyphVariantRecord, ensure that S is at least the advance width of the glyph of id MathGlyphVariantRecord.variantGlyph.
   2. If there is valid GlyphAssembly subtable, then ensure that S is at least the glyph assembly width.
3. Return S.

The algorithm to shape a stretchy glyph to inline (respectively block) dimension T is the following:

1. If there is not any MathGlyphConstruction table in the MathVariants.horizGlyphConstructionOffsets table (respectively MathVariants.vertGlyphConstructionOffsets table) for the given glyph then exit with failure.
2. If the glyph's advance width (respectively height) is at least T then use normal shaping and bounding box for that glyph, the MathItalicsCorrectionInfo for that glyph as italic correction and exit with success.
3. Browse the list of MathGlyphVariantRecord in MathGlyphConstruction.mathGlyphVariantRecord. If one MathGlyphVariantRecord.advanceMeasurement is at least T then use normal shaping and bounding box for MathGlyphVariantRecord.variantGlyph, the MathItalicsCorrectionInfo for that glyph as italic correction and exit with success.
4. If there is valid GlyphAssembly subtable then use the bounding box given by glyph assembly width, glyph assembly height, glyph assembly ascent, glyph assembly descent, the value GlyphAssembly.italicsCorrection as italic correction, perform shaping of the glyph assembly and exit with success.
5. If none of the stretch options above allowed to cover the target size T, then choose last one that was tried and exit with success.

The algorithm to get a glyph corresponding to a character c given a directionality dir is the following:

• Let g be the glyph corresponding to c in the first available font. If it is not possible to find such a glyph, then exit with failure.
• If dir is rtl:
  • If there exists an OpenType rtlm variant of g in the first available font, then return it and exit with success. [OPEN-FONT-FORMAT]
  • Otherwise, if c has the Bidi_Mirrored property [BIDI]:
    • If c has a corresponding mirrored codepoint, c', then return the glyph corresponding to c' and exit with success. If it is not possible to find such a glyph, then exit with failure.
    • Otherwise, exit with failure.
    Note

    These failure cases are for when a character should be mirrored according to its Bidi_Mirrored property, but no corresponding codepoint or glyph exists.
  • Otherwise, return g and exit with success.
• Assert: dir is ltr.
• Return g and exit with success.