This specification defines a core subset of Mathematical Markup Language, or MathML, that is suitable for browser implementation. MathML is a markup language for describing mathematical notation and capturing both its structure and content. The goal of MathML is to enable mathematics to be served, received, and processed on the World Wide Web, just as HTML has enabled this functionality for text.
This is a public copy of the editors’ draft. It is provided for discussion only and may change at any moment. Its publication here does not imply endorsement of its contents by W3C. Don’t cite this document other than as work in progress.
The [[MATHML3]] specification has several shortcomings that make it hard to implement consistently across web rendering engines or to extend with userdefined constructions e.g.
This MathML Core specification intends to address these issues by being as accurate as possible on the visual rendering of mathematical formulas using additional rules from the TeXBook’s Appendix G [[?TEXBOOK]] and from the Open Font Format [[OPENFONTFORMAT]], [[OPENTYPEMATHILLUMINATED]]. It also relies on modern browser implementations and web technologies [[HTML]] clarifying interactions with them when needed or introducing new lowlevel primitives to improve the web platform layering. Parts of MathML 3 that do not fit well in this framework or are rarely used in practice have been omitted. Instead, they are described in a separate and larger [[MATHML4]] specification.
By increasing the level of implementation details, focusing on a workable subset, following a browserdriven design and relying on automated web platform tests, this specification is expected to greatly improve MathML interoperability. Moreover, effort on MathML layering will enable users to implement the rest of the MathML 4 specification, or more generally to extend MathML Core, using modern web technologies such as shadow DOM, custom elements, CSS layout API or other Houdini APIs.
When parsing HTML documents user agents must treat any of the following MathML Core elements as belonging to the MathML namespace:
Users agents must allow mixing HTML, SVG and MathML elements as allowed by sections HTML integration point, MathML integration point, tree construction dispatcher, MathML and SVG from [[HTML]].
When evaluating the SVG
requiredExtensions
attribute, user agents must claim support for the language extension
identified by the
MathML namespace.
<math>
element can be used at
position permitted for
flow content
(e.g. a
<foreignObject>
element)
or phrasing content.
<mi>
,
<mo>
,
<mn>
,
<ms>
and
<mtext>
elements.
<svg>
element can be used inside
<annotationxml>
elements.
<annotationxml>
elements with
encoding
application/xhtml+xml
or text/html
.
User agents must support various CSS features mentioned in this specification, including new ones described in . They must follow the computation rule for display: contents.
All documents containing MathML Core elements must include
CSS rules described in
as part of useragent level style sheet defaults.
Rules relying on universal selectors such as
mfrac > *
or msub > :not(:firstchild)
may
be replaced with equivalent expanded rules listing all possible
MathML Core elements.
display: math
elements and set a default
style on <math>
root and tabular elements?
The following CSS features are not supported and must be ignored:
writingmode
is treated as horizontaltb
on all MathML
elements.whitespace
is treated as nowrap
on all MathML elements.
width
,
height
,
inlinesize
and
blocksize
are treated as auto
on elements
with computed display value math
.
float
and clear
are treated as none
on all MathML elements.
aligncontent
, justifycontent
,
alignself
, justifyself
have
no effect on MathML elements.
User agents supporting Web application APIs must ensure that they keep the visual rendering of MathML in synchronization with the [[DOM]] tree.
HTMLElement includes ElementCSSInlineStyle;
should be moved to the [[CSSOM]] specification.
All the nodes representing MathML Core elements in the DOM
must implement, and expose to scripts, the following
MathMLElement
interface.
The
GlobalEventHandlers
,
DocumentAndElementEventHandlers
and
HTMLOrForeignElement
interfaces are defined in
[[HTML]].
The
ElementCSSInlineStyle
interface is defined in [[CSSOM]].
Each IDL attribute of the
MathMLElement
interface
reflects the
corresponding MathML
content attribute.
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 [[OPENFONTFORMAT]] 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 focusrelated pseudoclasses as defined in CSS Selectors apply, as defined in that specification.
Any MathML elements containing an href attribute are valid links and are focusable. Their tabindex focus flag must be set unless the user agent normally provides an alternative method of keyboard traversal of links, and they appear in the sequential focus order.
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).
<integervalue>
value as defined in
[[CSSVALUES3]], whose first character is neither
U+002D HYPHENMINUS character () nor
U+002B PLUS SIGN (+).
<numbervalue>
value as defined in
[[CSSVALUES3]], whose first character is neither
U+002D HYPHENMINUS character () nor
U+002B PLUS SIGN (+).
<lengthpercentage>
value as defined in
[[CSSVALUES3]]
lengthpercentage
whose first character is neither
U+002D HYPHENMINUS character () nor
U+002B PLUS SIGN (+).
<color>
value as defined in [[CSSCOLOR3]]
true
or
false
.
The following attributes are common to and may be specified on all MathML elements:
data*
dir
displaystyle
href
mathbackground
mathcolor
mathsize
mathvariant
nonce
scriptlevel
style
tabindex
on*
event handler attributes
The
id
,
class
,
style
,
data*
,
nonce
and
tabindex
attributes have the same syntax and semantic as defined for
id,
class,
style,
data*,
nonce and
tabindex
attributes on HTML elements.
The
href
attribute has the same syntax and semantic as defined for
the href attribute on
<a>
element.
To fully implement this attribute, the following CSS properties for
links must be specified in the
user agent stylesheet:
The
dir
attribute, if present,
must be a caseinsensitive match
to ltr
or ltr
.
It is mapped to the
direction
CSS property.
This attribute is used to set the directionality of math formulas, which is
often rtl
in Arabic speaking world.
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.
The mathcolor
property describes the foreground fill color of
an MathML text, bars etc and the background color of an element.
They are mapped to the
color
and
backgroundcolor
CSS properties.
The
mathsize
attribute, if present, must
have a value that is a valid lengthpercentage.
The mathsize
property indicates indicates the desired height
of glyphs in math formulas but also scale other parts (spacing, shifts,
line thickness of bars etc) accordingly.
It is mapped to the CSS property
fontsize
and the mathsize
values are interpreted according to the
definition in [[CSSFONTS3]].
mathvariant
attribute
The
mathvariant
attribute,
if present, must be a caseinsensitive match to one of:
normal
,
bold
,
italic
,
bolditalic
,
doublestruck
,
boldfraktur
,
script
,
boldscript
,
fraktur
,
sansserif
,
boldsansserif
,
sansserifitalic
,
sansserifbolditalic
,
monospace
,
initial
,
tailed
,
looped
, or
stretched
.
The mathvariant
attribute defines logical classes of token
elements. Each class provides a collection of typographicallyrelated
symbolic tokens with specific meaning within a given mathematical
expression.
For mathvariant
values other than normal
,
this is done by using glyphs of
Unicode's Mathematical Alphanumeric Symbols.
Hence, the mathvariant
attribute
is mapped to new values of the CSS property
texttransform
.
More precisely, normal
is mapped to none
while all the other values the corresponding CSS value with the extra
math
prefix.
mathvariant
values other than normal
are implemented for compatibility with full MathML and legacy editors that can't access characters in Plane 1 of Unicode. Authors are encouraged to use the corresponding Unicode characters.
The normal
value is still important to cancel automatic
italic of the <mi>
element.
salt
or
ssXY
properties from [[OPENFONTFORMAT]]
to provide both styles. Page authors may use the
fontvariantalternates
property with corresponding OpenType font features
to access these glyphs.
displaystyle
and scriptlevel
attributes
The
displaystyle
attribute, if present, must have a value that is a boolean.
It is mapped to the CSS property mathstyle
.
More precisely, true
is mapped to display
and
false
to inline
.
This attribute indicate 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
unsignedinteger.
It is mapped to the mathscriptlevel
.
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 .
\displaystyle
, \textstyle
,
\scriptstyle
, and \scriptscriptstyle
correspond
to displaystyle
and scriptlevel
as
true
and 0
,
false
and 0
,
false
and 1
,
and false
and 2, respectively.
<math>
ElementMathML specifies a single toplevel 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 as well as the
following attribute:
The
display
attribute, if present,
must be a caseinsensitive match
to block
or inline
.
To fully implement this attribute, additional CSS properties must be
specified in the user agent stylesheet
as described in .
math
element is already inline
or
block
display, it should probably generate an anonymous
mrowlike box container?
The layout algorithm of the <math>
element
is the same as the <mrow>
element. User agents must
ensure correct baseline alignment, centering, sizing etc of the
<math>
element.
$...$
and inline mode $...$
correspond to
display="block"
and display="inline"
respectively.
The default display
property
is described in :
<math>
root,
inline
if the
or block
according to the
value of the display attribute.
<mtable>
,
<mtr>
,
<mtd>
it respectively
inlinetable
,
tablerow
and
tablecell
.
math
.
In order to specify math layout in different writing modes, this specification uses concepts from [[CSSWRITINGMODES3]]:
horizontallr
and ltr
.
See ,
and
for examples of other
writing modes that are sometimes used for math layout.
MathML boxes have several parameters in order to layout in a way that is compatible with CSS but also to take into account very accurate positions and spacing within math formulas. Each math box has the following parameters:
Block metrics. The block size, first baseline set and last baseline set. The following baselines are defined for MathML boxes:
Given a MathML box, the inline offset of a child box is the distance between the inlinestart edge of the parent box and the inlinestart edge of the child box. The block offset of a child box is the offset between blockstart edge of the parent box and the blockstart edge of the child box.
The lineleft offset, lineright offset, lineover offset and lineunder offset are defined similarly as offsets between the corresponding parent and child edges.
inline offset
and block offset
.
For convenience, the layout algorithms may describe offsets using
flowrelative directions, linerelative directions or
the baseline.
It is always possible to pass from one description to the other
because position of child boxes are always performed after the
metrics of the box and of its child boxes are calculated.
Here are examples of offsets obtained from linerelative metrics:
ltr
and
is the inline size of the box −
(lineleft offset + inline size of
the child box) otherwise.
horizontallr
,
verticalrl
or sidewaysrl
and is the linedescent otherwise.
The layout algorithms described in this chapter for MathML boxes have the following structure:
During box layout, the following extra steps must be performed:
The box metrics and offsets of the
padding box
is 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 or italic correction then the padding box has the same properties, increased by the inlinestart padding.
The box metrics and offsets of the
border box
is obtained from the
padding box
by taking into account the corresponding
borderwidth
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 lineover border is positive then the inkover baseline is set to the lineover edge of the border box and if the lineunder border is positive then the inkunder baseline is set to the lineunder edge of the border box.
If the padding box has a top accent attachment then the border box has the same top accent attachment value increased by the borderwidth of its inlinestart edge.
If the padding box has an italic correction and the borderwidth of the inlineend edge of the border box is zero then the border box has the same italic correction value increased by the borderwidth of its inlinestart edge.
The box metrics and offsets of the
margin box
is 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 border box has a top accent attachment or italic correction then the margin box has the same properties, increased by the inlinestart 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 lineascent and ink linedescent 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.
Token elements in presentation markup are broadly intended to represent the smallest units of mathematical notation which carry meaning. Tokens are roughly analogous to words in text. However, because of the precise, symbolic nature of mathematical notation, the various categories and properties of token elements figure prominently in MathML markup. By contrast, in textual data, individual words rarely need to be marked up or styled specially.
<mtext>
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 .
<mtext>
If the element does not have its computed
display
property equal to math
then it is laid out according to the CSS specification where
the corresponding value is described.
Otherwise, the layout below is performed.
The mtext
element is laid out as a
block box
and the mincontent/maxcontent inline sizes,
inline size, block size, first/last baseline sets are determined
accordingly.
If the <mtext>
element contains only text
content without
forced line break
or
soft wrap opportunity
then in addition:
<mtext>
element.
Good mathematical rendering requires use of nonUnicode glyphs.
Mathematical fonts may only provide these glyphs when the
math
script tag is enabled [[OPENFONTFORMAT]],
so user agents must
ensure that it is the case when rendering text inside the
<mtext>
element.
If on the <mtext>
element
the CSS property
direction
is rtl
,
then user agents must enable the rtlm
OpenType feature on text nodes [[OPENFONTFORMAT]]
unless it contradicts what the
page author has specified with the
fontfeaturesettings
CSS property.
Some characters like primes already have script size by default
and
hence would be too small when used in a script position.
To render such “prescripted” characters with the appropriate size,
If a <mtext>
has a positive
mathscriptlevel
value then user agents must
enable
the ssty
(Script Style) OpenType feature
on its text nodes [[OPENFONTFORMAT]]
unless it contradicts what the page author has
specified with the
fontfeaturesettings
CSS property.
<mi>
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 . Its layout algorithm is
the same as the <mtext> element.
The
user agent stylesheet
must contain the following property in order to implement automatic
italic:
<mn>
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 . Its layout algorithm is
the same as the
<mtext>
element.
<mo>
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 as well as the following
attributes:
A MathML Core element is an embellished operator if is is:
<mo>
element;<msub>
,
<msup>
,
<msubsup>
,
<munder>
,
<mover>
,
<munderover>
,
<mmultiscripts>
,
<mfrac>
,
<semantics>
or
<maction>
whose first inflow child exists and is an
embellished operator;
<mrow>
,
<mstyle>
,
<mphantom>
,
<mpadded>
whose inflow children consist (in any order) of one
embellished operator and zero or more
spacelike elements.
The core operator of an embellished operator
is the <mo>
element defined recursively as
follows:
<mo>
element; is the element itself.<msub>
,
<msup>
,
<msubsup>
,
<munder>
,
<mover>
,
<munderover>
,
<mmultiscripts>
,
<mfrac>
,
<semantics>
or
<maction>
element is the core operator of its first inflow child.
<mrow>
,
<mstyle>
,
<mphantom>
,
<mpadded>
is the core operator of its unique embellished operator
inflow child.
The stretch axis of an embellished operator
is inline if its
core operator contains only text content
made of a unique character c
and that
character has stretch axis inline per
.
Otherwise, stretch axis of the embellished operator
is block.
The form
property of an embellished operator
element must be a caseinsensitive match to infix
, prefix
or
postfix
.
The form
attribute can only be defined on its core operator (an
<mo>
element).
The form
of the embellished operator is determined as follows:
form
attribute is present and valid
on the core operator, then its value is used;
prefix
;
<math>
,
<menclose>
,
<merror>
,
<mpadded>
,
<mphantom>
,
<mrow>
,
<msqrt>
or
<mstyle>
element
with more than one inflow child
(ignoring all spacelike children) then it has
form postfix
;
<msub>
,
<msup>
,
<msubsup>
,
<munder>
,
<mover>
,
<munderover>
or
<mmultiscripts>
element other than the first inflow child, then it has form
postfix
;
infix
.
The
fence
,
separator
,
stretchy
,
symmetric
,
largeop
,
movablelimits
,
accent
properties of an embellished operator are is either
true
or false
. In the former case, it
is said that the embellished operator has the
property.
The corresponding attributes can only be defined on their core operator (an
<mo>
element) and must be boolean.
The
lspace
,
rspace
,
minsize
properties of an embellished operator are
lengthpercentage.
The maxsize
property
of an embellished operator is either an
lengthpercentage or infinity
.
The
lspace
,
rspace
,
minsize
and
maxsize
attributes can only be defined on their core operator (an
<mo>
element) and must be lengthpercentage.
The
fence
,
separator
,
stretchy
,
symmetric
,
largeop
,
movablelimits
,
accent
,
lspace
,
rspace
,
maxsize
,
minsize
properties of
an embellished operator are determined as follows:
Content=T,Form=F
where F
is the form
of the
embellished operator;
form
of embellished operator was not explicitly specified
as an attribute on its core operator, then
user agents must try other dictionary entries for different
values of F
in the following order:
infix
, prefix
, postfix
;
false
for
fence
,
separator
,
stretchy
,
symmetric
,
largeop
,
movablelimits
and
accent
properties ;
0.2777777777777778em
for
lspace
and
rspace
properties ;
100%
for the minsize
property and
infinity
for the maxsize
property.
Percentage values for lspace
,
rspace
properties of an embellished operator
are interpreted relative to the value read from the dictionary
or to the fallback value above.
Percentages value for minsize
and
maxsize
properties of an embellished operator
are interpreted relative to
the target stretch size before application of
size constraints, as described in
.
fence
and separator
properties do not
have any visible effect on the layout described in this
specification. However, they can still be useful e.g. to provide
extra semantic information to assistive technlologies via the
accessible tree.
If the <mo>
element does not have its computed
display
property equal to math
then it is laid out according to the CSS specification where
the corresponding value is described.
Otherwise, the layout below is performed.
The text of the operator must only be painted if the
visibility
of
the <mo>
element is visible
.
In that case, it must be painted with the
color
of the <mo>
element.
Operators are laid out as follows:
<mo>
element is not
made
of a single character c
then fallback to the
layout algorithm of .
MathVariants.horizGlyphConstructionOffsets
table from the glyph corresponding to
c
in the current font, or otherwise
from the entry
with base character c
.
If that's not possible then
fallback to the
layout algorithm of .
T_{inline}
then
fallback to the
layout algorithm of .
T_{inline}
.
T
and
at position determined by the previous box metrics.
MathVariants.vertGlyphConstructionOffsets
table from the glyph corresponding to
c
in the current font, or otherwise
from the entry of
with base character c
.
If that's not possible then
fallback to the
layout algorithm of .
(T_{ascent}, T_{descent})
then
fallback to the
layout algorithm of .
T_{ascent}
+
T_{descent}
.
The inline size is the stretchy glyph width returned.
If Δ = T_{ascent}
+
T_{descent}
−
(stretchy glyph ascent + stretchy glyph descent)
then the ink ascent of the content is
T_{ascent}
+ Δ/2
and the ink descent of the content is
T_{descent}
+ Δ/2.
The ascent and descent of the content
are the same as the ink
ascent and ink descent of the content.
T
and
at position determined by the previous box metrics
shifted by Δ/2 towards the lineover.
mathstyle
on
the <mo>
element is display
,
then:
Use the
MathVariants
table to try and find a glyph of height at least
DisplayOperatorMinHeight
If none is found, fallback to the
largest nonbase glyph. If none is found, fallback to
the layout algorithm of .
Because this parameter does not always give the best size, user agents may also use the following heuristic: ensure that the large variant height is at least 2 times as large as the base height for integrals and √2 times as large as the base height for other operators.
<mspace>
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 as well as the following
attributes:
The
mspace@width
,
mspace@height
,
mspace@depth
, if present, must
have a value that is a valid lengthpercentage.
An unspecified attribute, a percentage value, or an invalid value
is interpreted as 0
.
If one of the requested values calculated is negative then it is
treated as 0
.
If the <mspace>
element does not have its
computed
display
property equal to 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
.
The mincontent and maxcontent inline sizes of the content are
equal to the requested inline size.
The inline size, lineascent and linedescent of the content
are respectively
the requested inline size, lineascent and linedescent.
The ink lineascent (respectively ink linedescent) of the content
is the same
as the lineascent (respectively linedescent) of the content.
A number of MathML presentation elements are "spacelike" in the sense that they typically render as whitespace, and do not affect the mathematical meaning of the expressions in which they appear. As a consequence, these elements often function in somewhat exceptional ways in other MathML expressions.
A MathML Core element is a spacelike element if is is:
<mtext>
or
<mspace>
.
<mrow>
,
<mstyle>
,
<mphantom>
,
<mpadded>
element
all of whose inflow children are spacelike;
<maction>
or <semantics>
element
whose first inflow child exists and is spacelike.
<mphantom>
is not
automatically defined to be spacelike, unless its content is
spacelike. This is because operator spacing is affected by
whether adjacent elements are spacelike.
Since the <mphantom>
element is
primarily intended as an aid in aligning expressions, operators
adjacent to an <mphantom>
should behave
as if they were adjacent to the contents of the
<mphantom>
, rather than to an equivalently
sized area of whitespace.
<ms>
<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 <mn>
element accepts the attributes described
in as well as the following
attributes:
The
lquote
,
rquote
attributes respectively specify the strings to use as opening and
closing quotes. An unspecified attribute is
interpreted as the character U+0022 QUOTATION MARK.
The layout algorithm is the same as the
<mtext>
element.
The user agent stylesheet
must contain the following rules in order to enclose the content with
quotes:
Besides tokens there are several families of MathML presentation elements. One family of elements deals with various "scripting" notations, such as subscript and superscript. Another family is concerned with matrices and tables. The remainder of the elements, discussed in this section, describe other basic notations such as fractions and radicals, or deal with general functions such as setting style properties and error handling.
<mrow>
The
<mrow>
element is used to group together any number of subexpressions, usually
consisting of one or more <mo>
elements acting as
"operators" on one or more other expressions that are their "operands".
The <mrow>
element accepts the attributes described
in . An <mrow>
element with inflow children
child_{1}, child_{2}, … child_{N}
is laid out as show on . The child boxes
are put in a row one after the other with all their baselines
aligned.
The Algorithm for stretching operators along the block axis consists in the following steps:
<mrow>
but the
embellished operators that have
the stretchy property and block stretch axis.
If this step results in all the inflow children
being laid out, then
stop.
U_{ascent}
and U_{descent}
as respectively the maximum
ink ascent and maximum ink descent of the margin boxes of
inflow children that
have been laid out in the previous step.
S_{ascent}
=
max(
U_{ascent}
− AxisHeight,
U_{descent}
+ AxisHeight
) + AxisHeight
S_{ascent}
=
max(
U_{ascent}
− AxisHeight,
U_{descent}
+ AxisHeight
) + AxisHeight
<mrow>
that is an embellished operator
with the stretchy property and block stretch axis:
T_{ascent}
and
T_{descent}
to
S_{ascent}
and
S_{descent}
respectively.
Otherwise set them to
U_{ascent}
and
U_{descent}
respectively.
minsize
and maxsize
be the minsize and maxsize properties on the
child. Percentage values are intepreted relative
to T
=
T_{ascent}
+
T_{descent}
.
If 0 ≤ minsize
≤ maxsize
then:
T
= 0 then set
T_{ascent}
and
T_{descent}
to minsize
/2.
T
< minsize
then
multiply
T_{ascent}
,
T_{descent}
by minsize
/ T
.
maxsize
< T
then multiply
T_{ascent}
,
T_{descent}
by maxsize
/ T
.
(T_{ascent}, T_{descent})
.
<mrow>
If the element does not have its computed
display
property equal to math
then it is laid out according to the CSS specification where
the corresponding value is described.
Otherwise, the layout below is performed.
A child box is slanted if it is not an embellished operator and has nonzero italic correction.
lspace
and
rspace
.
The mincontent (respectively maxcontent) inline size are calculated using the following algorithm:
addspace
to true if
the <mrow>
is not an
embellished operator; and to false otherwise.
inlineoffset
to 0.previousitaliccorrection
to 0.inlineoffset
by
previousitaliccorrection
.
addspace
is true then
increment inlineoffset
by
its lspace
property.
inlineoffset
by
the mincontent (respectively maxcontent) inline size of
the child's margin box.
previousitaliccorrection
to
its italic correction. Otherwise set it to 0.
addspace
is true then
increment inlineoffset
by
its rspace
property.
inlineoffset
by
previousitaliccorrection
.
inlineoffset
.
The inflow children are laid out using the algorithm for stretching operators along the block axis.
The inline size of the content is calculated like the mincontent and maxcontent inline sizes of the content, using the inline size of the inflow children's margin boxes instead.
The (ink) lineascent of the content is the maximum of the (ink) lineascents of all the inflow children's margin boxes. Similarly, the (ink) linedescent of the content is the maximum of the (ink) linedescents of all the inflow children's margin boxes.
Finally, the inflow children are positioned using the following algorithm:
addspace
to true if
the <mrow>
is not an
embellished operator; and to false otherwise.
inlineoffset
to 0.previousitaliccorrection
to 0.inlineoffset
by
previousitaliccorrection
.
addspace
is true then
increment inlineoffset
by
its lspace
property.
inlineoffset
and its block offset such
that the baseline of the child is aligned with the baseline.
inlineoffset
by
the inline size of the child's margin box.
previousitaliccorrection
to
its italic correction. Otherwise set it to 0.
addspace
is true then
increment inlineoffset
by
its rspace
property.
<mfrac>
The
<mfrac>
element is used for fractions. It can also be used to mark up
fractionlike objects such as binomial coefficients and Legendre symbols.
If the <mfrac>
element does not have its computed
display
property equal to 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 as well as the
following attribute:
The
linethickness
attribute indicates the thickness to use for the fraction bar.
If present, it must
have a value that is a valid lengthpercentage.
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.
The <mfrac>
element sets
displaystyle
to false
,
or if it was already false
increments
scriptlevel
by 1, within its children.
To avoid visual confusion between the fraction bar and another
adjacent items (e.g. minus sign or another fraction's bar),
a default 1pixel space is added around the element.
The user agent stylesheet
must contain the following rules:
If the <mfrac>
element
has less or more than two inflow children, its layout algorithm
is the same as the <mrow>
element.
Otherwise, the first inflow child is called
numerator, the second inflow child is called
denominator and the layout algorithm is explained below.
<mfrac>
element has two children
that are inflow. Hence the CSS rules basically performs
scriptlevel and displaystyle changes for the numerator and
denominator.
If the actual line thickness is nonzero, the
<mfrac>
element is laid out as shown on .
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 mincontent (respectively maxcontent) inline size of content is the maximum between the mincontent (respectively maxcontent) inline size of the numerator's margin box and the mincontent (respectively maxcontent) 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 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:
inline
(respectively display
).
inline
(respectively display
) +
the ink linedescent of the numerator's margin box.
DenominatorShift
is the maximum between:
inline
(respectively display
).
inline
(respectively display
) +
the ink lineascent of the denominator's margin box −
the AxisHeight.
The (ink) lineascent of the content is the maximum between:
Numerator Shift
+
the (ink) lineascent of the numerator's margin box.
Denominator Shift
+
the (ink) lineascent of the denominator's margin box
The (ink) linedescent of the content is the maximum between:
Numerator Shift
+ the (ink) linedescent of the numerator's margin box.
Denominator Shift
+ the (ink) linedescent of the denominator's margin box.
The inline offset of the numerator (respectively denominator) is the half the inline size of the content − half the inline size of the numerator's margin box (respectively denominator's margin box).
The baseline of the numerator (respectively denominator)
is shifted away from the baseline by a distance of
NumeratorShift
(respectively
DenominatorShift
)
towards the lineover (respectively lineunder).
The inline size of the fraction bar is the inline size of the content and its inline offset is 0. The center of the fraction bar is shifted away from the baseline by a distance of AxisHeight towards the lineover. Its block size is the line thickness.
If the actual line thickness is zero,
the <mfrac>
element is instead laid out as
shown on .
The mincontent inline size, maxcontent inline size and inline size of the content are calculated the same as in .
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 mathstyle is inline
then
TopShift
and
BottomShift
are respectively
set to StackTopShiftUp and StackBottomShiftDown.
Otherwise mathstyle is display
) and
they are respectively set to StackTopDisplayStyleShiftUp
and StackBottomDisplayStyleShiftDown).
The Gap
is defined to be
(BottomShift
−
the ink lineascent of the denominator's margin box) +
(TopShift
−
the ink linedescent of the numerator's margin box).
If mathstyle is inline
then GapMin
is StackGapMin
otherwise mathstyle is display
and it is StackDisplayStyleGapMin.
If Gap
is not at least GapMin
then
TopShift
and BottomShift
are increased by
half GapMin
− Gap
.
The (ink) lineascent of the content is the maximum between:
TopShift
+
the (ink) lineascent of the numerator's margin box.
BottomShift
+ the (ink) lineascent of the denominator's margin box.
The (ink) linedescent of the content is the maximum between:
TopShift
+ the (ink) linedescent of the numerator's margin box.
BottomShift
+ the (ink) linedescent of the denominator's margin box.
The inline offsets of the numerator and denominator are calculated the same as in .
The baseline of the numerator (respectively denominator) is
shifted away from the baseline by a distance of
TopShift
(respectively −
BottomShift
) towards the
lineover (respectively lineunder).
<msqrt>
, <mroot>
The
<msqrt>
and
<mroot>
elements construct radicals. 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 .
The <mroot>
element sets
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:
If the <msqrt>
or <mroot>
element do not have their computed
display
property equal to 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
inflow children,
its layout algorithm
is the same as the <mrow>
element.
Otherwise, the first inflow child is called
base and
the second inflow child is called
index
and its layout algorithm is explained below.
<mroot>
element has two children
that are inflow. Hence the CSS rules basically performs
scriptlevel and displaystyle changes for the index.
The children of the
<msqrt>
element are laid out
using the algorithm of the <mrow>
element
to produce a box that is also called the base.
In particular, the
algorithm for stretching operators along the block axis is used.
The radical symbol must only be painted if the
visibility
of
the <msqrt>
or <mroot>
element is visible
.
In that case, the radical symbol must be painted with the
color
of that element.
The radical glyph is the glyph obtained for the
character U+221A SQUARE ROOT,
applying the rtlm
OpenType feature
if the CSS property
direction
is rtl
[[OPENFONTFORMAT]].
The radical gap is given by
RadicalVerticalGap
if the mathstyle is inline
and
RadicalDisplayStyleVerticalGap
if the mathstyle is display
.
The radical target size for the stretchy radical glyph is the sum of RadicalRuleThickness, radical gap and the ink height of the base.
The box metrics of the radical glyph is the box metrics of a stretchy glyph stretched to block dimension the target size for the radical glyph.
The shaping of the surd is performed by the algorithm to shape a stretchy glyph to block dimension the target size for the radical glyph.
The <msqrt>
element is laid out as shown on
.
The mincontent (respectively maxcontent) inline size of the content is the sum of the preferred inline size of a glyph stretched along the block axis for the radical glyph and of the mincontent (respectively maxcontent) inline size of the base's margin box.
The inline size of the content is the sum of the advance width of the box metrics of the radical glyph and of the inline size of the base's margin's box.
The ink lineascent of the content is the sum of RadicalRuleThickness, the radical gap and the ink lineascent of the base's margin box. The lineascent of the content is the maximum between:
The (ink) linedescent of the content is the maximum between:
The inline size of the overbar is the inline size of the base's margin's box. The inline offsets of the base and overbar are also the same and equal to the width of the box metrics of the radical glyph.
The baseline of the base is aligned with the baseline. The block size of the overbar is RadicalRuleThickness. It lineover edge is shifted away from the baseline by a distance towards the lineover equal to the ink lineascent of the content.
Finally, the shaping of the surd is performed:
The <mroot>
element is laid out as shown on
.
The root index is first ignored and the base and
radical glyph
are laid out as
shown on figure
so that the content is represented by a box B.
The mincontent (respectively maxcontent) inline size of the content is the sum of RadicalKernBeforeDegree, the index mincontent (respectively maxcontent) inline size of the index's margin box, RadicalKernAfterDegree and of the mincontent (respectively maxcontent) of B.
The inline size of the content is the sum of RadicalKernBeforeDegree, the inline size of the index's margin box, RadicalKernAfterDegree and of the inline size of B.
The (ink) lineascent of the content is the maximum between:
The (ink) linedescent of the content is the maximum between:
The inline offset of the index is RadicalKernBeforeDegree. The inlineoffset of the base is the same + the inline size of the index's margin box.
The baseline of B is aligned with the baseline. The baseline of the index is shifted away from the lineunder edge by a distance of RadicalDegreeBottomRaisePercent × the ink block size of B + the ink linedescent of the index's margin box.
<mstyle>
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
. Its layout algorithm is the
same as the <mrow>
element.
<mstyle>
is implemented for compatibility with full MathML. Authors whose only target is MathML Core are encouraged to use CSS for styling.
<merror>
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.
The <merror>
element accepts the attributes described in
. 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:
<mpadded>
The
<mpadded>
element renders the same as its inflow 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 as well as the following
attributes:
The
mpadded@width
and
mpadded@lspace
attributes, if present, must match the syntax
( "+"  "" )? (
.
unsignedlengthpercentage
 (unsignednumber
"%"? "width"))
The
mpadded@height
,
mpadded@depth
and
mpadded@voffset
attributes, if present, must match the syntax
( "+"  "" )? (
.
unsignedlengthpercentage
 (unsignednumber
"%"? ("height"  "depth"))
Inflow children
of the <mpadded>
element are laid out
using the algorithm of the <mrow>
element
to produce the
mpadded inner box for the content with parameters called
inner inline size, inner lineascent and inner linedescent.
The requested <mpadded>
parameters are determined as follows:
width
(respectively height
,
depth
, lspace
, voffset
)
attributes are absent or invalid the requested width
(respectively height, depth, lspace, voffset)
is the inner inline size
(respectively inner lineascent, inner linedescent,
0
,
0
).
width
(respectively height
,
depth
, lspace
, voffset
)
attribute is an
unsignedlengthpercentage
then the requested width
(respectively height, depth, lspace, voffset)
is the resolved value
with percentage interpreted relative to
the inner inline size (respectively
inner lineascent, inner linedescent, 0
,
0
).
width
(respectively lspace
) attribute
matches "unsignednumber
width"
then the requested width (respectively lspace) is the number multipled by
the inner inline size. If instead it matches
"unsignednumber
%width"
then it is the same value but divided by 100.
height
(respectively depth
,
voffset
) attribute
matches "unsignednumber
height"
then the requested height (respectively depth, voffset) is the number
multipled by the inner lineascent. If instead it matches
"unsignednumber
%heigth"
then it is the same value but divided by 100.
height
(respectively depth
,
voffset
) attribute
matches "unsignednumber
depth"
then the requested height (respectively depth, voffset) is the number
multipled by the inner linedescent. If instead it matches
"unsignednumber
%depth"
then it is the same value but divided by 100.
width
(respectively height
,
depth
, lspace
, voffset
)
starts with a U+002B PLUS SIGN or U+002D HYPHENMINUS character,
then choose ε = ±1 to match the sign of that character
and let V be the requested width
(respectively height, depth, lspace, voffset)
obtained for the same attribute value with that character removed.
Then the requested width (respectively height, depth, lspace, voffset)
is the inner inline size (respectively inner lineascent,
inner linedescent, 0
,
0
) + εV.
If one of the requested width, depth, height or lspace values calculated
above is negative then it is treated as 0
.
<mpadded>
If the <mpadded>
element does not have its
computed
display
property equal to 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
.
The mincontent (respectively maxcontent) inline size of the content is the requested width calculated in but using the mincontent (respectively maxcontent) inline size of the mpadded inner box instead of the "inner inline size".
The inline size of the content is the requested width calculated in .
The (ink) lineascent of the content is the requested height. The (ink) linedescent of the content is the requested depth.
The mpadded inner box is placed so that its baseline is shifted away from the baseline by the requested voffset towards the lineover.
<mphantom>
Historically, the
<mphantom>
element was introduced to render
its content invisibly, but with the same size and other dimensions,
including baseline position, that its contents would have if they were
rendered normally.
The <mphantom>
element accepts the attributes described
in . 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>
is implemented for compatibility with full MathML. Authors whose only target is MathML Core are encouraged to use CSS for styling.
<menclose>
The
<menclose>
element renders its content inside the enclosing notation.
It accepts the attributes described in
as well as the
following attribute:
The
notation
attribute, if present, must have a value that is an
unordered set
of unique spaceseparated tokens that are ASCII caseinsensitive. The
allowed values are
left
,
right
,
top
,
bottom
,
box
,
roundedbox
,
actuarial
,
madruwb
,
horizontalstrike
,
verticalstrike
updiagonalstrike
,
downdiagonalstrike
,
longdiv
,
circle
.
If the <menclose>
element does not have its
computed
display
property equal to math
then it is laid out according to the CSS specification where
the corresponding value is described.
Otherwise, the layout below is performed.
The notations must only be painted if the
visibility
of
the <menclose>
element is visible
.
In that case, the notations must be painted with the
color
of the <menclose>
element.
Inflow
children of the <menclose>
element are laid out
using the algorithm of the <mrow>
element
to produce a box B corresponding to the content.
In particular, they use the
algorithm for stretching operators along the block axis.
ξ_{8} is used below to denote the
default rule thickness and is set to OverbarRuleThickness.
If the notation
attribute contains the
box
value,
then it is treated as it was replaced with the set of values
left right top bottom
, removing duplicates values
with the other of the notations, if any.
Similarly, actuarial
and
madruwb
notations are respectively treated as
equivalent to right top
and
and right bottom
.
The layout of other individual notation is explained in the
following sections. In general when the notation
attribute contains multiple
values, each algorithm is applied individually to obtain
boxes B_{1}, B_{2}, ... B_{n}
corresponding to their content. The layout
of the <menclose>
element is then performed
as follows:
longdiv
notation: In that case,
s_{left,i} is replaced with the
preferred inline size of a glyph stretched along the block axis
for U+0029 RIGHT PARENTHESIS.
Again, it is possible to take the maximum values to calculate
the mincontent and maxcontent inline sizes of the content.
For the left
notation, a bar is drawn
on the lineleft side along the block axis
as shown on .
The mincontent (respectively maxcontent) inline size of the content is the mincontent (respectively maxcontent) inline size of B + 5ξ_{8}.
The inline size is the inline size of B + 5ξ_{8}, the ink lineascent of the content is the one of B + OverbarVerticalGap + OverbarRuleThickness and the ink linedescent of the content is the one of B + UnderbarVerticalGap + UnderbarRuleThickness. The lineascent (respectively linedescent) of the content is the maximum of between the ink lineascent (respectively ink linedescent) of the content and the lineascent (respectively linedescent) of B.
B is placed so that its baseline matches the baseline and its lineleft offset is 5ξ_{8}. The inline size of the bar is ξ_{8}, its block size is the block size of the content, its lineleft offset is ξ_{8} and its lineover offset is 0.
The right
notation is handled the same as the
left
notation,
but with the bar placed on the lineright side. The block
metrics, mincontent inline size, maxcontent inline size
and inline size of the content are the same.
The inline size of the bar is ξ_{8}, its lineleft offset is the inline size − 2ξ_{8} and the lineleft offset of B is 0.
For the top
notation, a bar is drawn
on the lineover side along the inline axis
as shown on .
The mincontent (respectively maxcontent) inline size of the content is the mincontent (respectively maxcontent) inline size of B + 8ξ_{8}.
The inline size of the content is the inline size of B + 8ξ_{8}, the ink lineascent of the content is the one of B + OverbarVerticalGap + OverbarRuleThickness. The inline lineascent of the content is the maximum between the lineascent of B and the ink lineascent of the content + OverbarExtraAscender. The (ink) linedescent of the content is the (ink) linedescent of B.
B is placed so that its baseline matches the baseline and its lineleft offset is 4ξ_{8}. The inline size of the bar is the inline size of the content, its block size is OverbarRuleThickness, its lineleft offset is 0 and its lineover offset is the ascent − the ink lineascent of B − OverbarVerticalGap − OverbarRuleThickness.
The bottom
notation is drawn the same as the
top
notation,
but with the bar placed on the lineunder side of B and using
parameters
UnderbarRuleThickness,
UnderbarVerticalGap
and UnderbarExtraDescender.
The inline metrics are the same.
The ink linedescent of the content is the one of B + UnderbarVerticalGap + UnderbarRuleThickness. The inline linedescent of the content is the maximum between the linedescent of B and the ink linedescent of the content + UnderbarExtraDescender. The (ink) lineascent of the content is the (ink) lineascent of B.
B is placed so that its baseline matches the baseline. The block size of the bar is UnderbarRuleThickness and its lineover offset is the lineascent of the content + the ink linedescent of B + UnderbarVerticalGap.
For the horizontalstrike
notation,
the metrics are the same as B.
A bar of inline size the inline size of the content and
of block size ξ_{8} is drawn
at lineover position minus half ξ_{8}.
See .
For the verticalstrike
notation,
the metrics are the same as B.
A bar of inline size ξ_{8} and
of block size the block size of the content is drawn
at lineleft position
half the inline size of the content minus half ξ_{8}.
For the updiagonalstrike
notation,
a bar is drawn
going from the lineleft lineunder corner to the
lineright lineover corner as shown on
.
The mincontent inline size, maxcontent inline size and inline size of the content are the one of B + ξ_{8}.
The ink lineascent and lineascent of the content are the lineascent of B + half ξ_{8}. The ink linedescent and linedescent of the content are the linedescent of B + half ξ_{8}.
B is placed so that its baseline is the baseline and its lineleft offset is half ξ_{8}.
Using terminology from [[SVG]],
the bar is drawn with a line
of thickness ξ_{8} going from the
lineunder lineleft corner of B
to the lineover lineright corner of B with
strokelinecap
set to butt
.
For the downdiagonalstrike
notation,
a bar is drawn
going from the lineleft lineover corner to the
lineright lineunder corner. The metrics are the same as
for the updiagonalstrike
notation.
The roundedbox
notation is drawn as
shown on .
The mincontent inline size, maxcontent inline size and inline size of the content are the ones of B plus 10ξ_{8}.
The ink lineascent (respectively linedescent) of the content is the ink lineascent (respectively linedescent) of B + 4ξ_{8}. The lineascent (respectively linedescent) of the content is the maximum between the lineascent (respectively linedescent) of B and the ink lineascent (respectively linedescent) of the content plus ξ_{8}.
B is placed so that its baseline is the baseline and
its lineleft offset is 5ξ_{8}.
If B' is the ink box B expanded on each side by
½7ξ_{8} then using terminology from [[SVG]],
a rounded rectangle is drawn on B'
with parameters rx
, ry
and
strokewidth
set to 3ξ_{8}.
The longdiv
notation is drawn similarly to the
<msqrt>
element
()
except that the CSS
direction
is ignored and U+221A SQUARE ROOT is replaced with
U+0029 RIGHT PARENTHESIS. The rule thickness is ξ_{8},
the gap between content and overbar is 3ξ_{8} and the
extra ascender is ξ_{8}.
The circle
notation is drawn as shown
on .
Given the ink box of width w and height h, an ellipse is drawn using
the axes of symmetry of this ink box, the radii
w x ½√2, h x ½√2 and thickness ξ_{8}.
Space of ξ_{8} is added each side of the ellipse's ink
box.
The mincontent inline size, maxcontent inline size and inline size of the content are the ones of B times √2 plus 3ξ_{8}.
The ink lineascent (respectively linedescent) of the content is the ink lineascent (respectively linedescent) of B times √2 plus ½ξ_{8}. The lineascent (respectively linedescent) of the content is the maximum between the lineascent (respectively linedescent) of B and the ink lineascent (respectively linedescent) of the content plus ξ_{8}.
Finally, B is placed so that its baseline is aligned with the baseline and its lineleft offset is ½(√2 − 1) times the inline size of B plus 3ξ_{8}/2.
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 generalpurpose element could suffice for positioning scripts and embellishments in any of the traditional script locations around a given base. However, in order to capture the abstract structure of common notation better, MathML provides several more specialized scripting elements.
In addition to sub/superscript elements, MathML has overscript and underscript elements that place scripts above and below the base. These elements can be used to place limits on large operators, or fo placing accents and lines above or below the base.
A MathML Core element is cramped if it satisfies one of the following condition:
<msqrt>
or
<mroot>
element.
<mfrac>
element.<msub>
or
<msubsup>
element.
<munder>
or
<munderover>
element.
<mover>
and <munderover>
elements and
is an embellished operator with
the accent
property.
<msub>
, <msup>
, <msubsup>
The <msub>
,
<msup>
and
<msubsup>
elements are used to attach
subscript and superscript to a MathML expression.
They accept the attributes described in
.
If the
<msub>
,
<msup>
or
<msubsup>
elements do not have their
computed
display
property equal to math
then they are laid out according to the CSS specification where
the corresponding value is described.
Otherwise, the layout below is performed.
<msub>
,
<msup>
, <msubsup>
If the <msub>
element
has less or more than two inflow children, its layout algorithm
is the same as the <mrow>
element.
Otherwise, the first inflow child is called the
base, the second inflow child is called the
subscript and the layout algorithm is explained
in .
If the <msub>
element
has less or more than two inflow children, its layout algorithm
is the same as the <mrow>
element.
Otherwise, the first inflow child is called the
base, the second inflow child is called the
superscript and the layout algorithm is explained
in .
If the <msubsup>
element
has less or more than three inflow children, its layout algorithm
is the same as the <mrow>
element.
Otherwise, the first inflow child is called the
base, the second inflow child
is called the subscript,
its third inflow child is called
the superscript and the layout algorithm is explained
in .
The <msub>
element is laid out as shown on
.
LargeOpItalicCorrection
is the italic correction of the base
if it is an embellished operator with
the largeop
property and 0 otherwise.
The contentmin (respectively contentmax) inline size
of the content is the contentmin (respectively maxcontent)
inline size of the base's margin box −
LargeOpItalicCorrection
+
the contentmin (respectively maxcontent) inline size of
the subscript's margin box + SpaceAfterScript.
If there is an inline stretch size constraint or a block stretch size constraint then the base is also laid out with the same stretch size contraint 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 content
is the inline size of the base's margin box −
LargeOpItalicCorrection
+
the inline size of
the subscript's margin box + SpaceAfterScript.
SubShift
is the maximum between:
The (ink) lineascent of the content is the maximum between:
SubShift
.The (ink) linedescent of the content is the maximum between:
SubShift
.
The inline offset of the base is 0 and the inline offset of the
subscript is the inline size of the base's margin box −
LargeOpItalicCorrection
.
The base is placed so that its baseline
matches the baseline. The subscript is placed so that its baseline
is shifted away from the baseline by SubShift
towards the lineunder.
The <msup>
element is laid out as shown on
.
ItalicCorrection
is the italic correction of the base
if it is not an embellished operator with
the largeop
property and 0 otherwise.
The contentmin (respectively contentmax) inline size
of the content
is the contentmin (respectively maxcontent)
inline size of the base's margin box +
ItalicCorrection
+
the contentmin (respectively maxcontent) inline size of
the superscript's margin box + SpaceAfterScript.
If there is an inline stretch size constraint or a block stretch size constraint then the base is also laid out with the same stretch size contraint 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 content
is inline size of the base's margin box +
ItalicCorrection
+
the inline size of
the superscript's margin box + SpaceAfterScript.
SuperShift
is the maximum between:
<msup>
element is
cramped or
the value SuperscriptShiftUp otherwise.The (ink) lineascent of the content is the maximum between:
SuperShift
.The (ink) linedescent of the content is the maximum between:
SuperShift
.
The inline offset of the base is 0 and the inline offset of
superscript is the inline size of the base's margin box +
ItalicCorrection
.
The base is placed so that its baseline
matches the baseline. The superscript is placed so that its
baseline
is shifted away from the baseline by SuperShift
towards the lineover.
The <msubsup>
element is laid out as shown on
.
LargeOpItalicCorrection
and SubShift
are set as in .
ItalicCorrection
and SuperShift
are set as in .
The mincontent inline size (respectively maxcontent inline size, inline size) of the content is the maximum between the of the inline sizes (respectively maxcontent inline size, inline sizes) of the content calculated in and .
If there is an inline stretch size constraint or a block stretch size constraint then the base is also laid out with the same stretch size contraint 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 base is also laid out with the same stretch size contraint 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 lineascent of the subscript's
margin box) +
(SuperShift
− the ink linedescent of the
superscript's margin box).
If SubSuperGap
is not at least
SubSuperscriptGapMin then the following steps are
performed to ensure that the condition holds:
SuperShift
− the ink linedescent of the
superscript's margin box).
If Δ > 0 then set Δ to the minimum between Δ set
SubSuperscriptGapMin − SubSuperGap
and
increase SuperShift
(and so
SubSuperGap
too) by Δ.
SubSuperGap
.
If Δ > 0 then
increase SubscriptShift
(and so
SubSuperGap
too) by Δ.
The ink lineascent (respectively lineascent, ink linedescent,
linedescent) of the content
is set to the maximum
of the
ink lineascents (respectively lineascents, ink linedescents,
linedescents) of the content
calculated in
in and
but using the adjusted values SubShift
and
SuperShift
above.
The inline and block offsets of the base and scripts are performed the same as described in and .
Even when the subscript (respectively superscript) is an empty
box, <subsup>
does not generally render the same as
(respectively )
because of the additional constraint on
SubSuperGap
.
Moreover, positioning the empty subscript
(respectively 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.
<munder>
, <mover>
, <munderover>
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 as well as the
following attributes:
Similarly, the <mover>
element
(respectively <munder>
element) accepts the
attribute described in
as well as the accent
attribute (respectively the
accentunder
attribute).
munderover@accent
,
munderover@accentunder
,
attributes, if present, must have values that are booleans.
User agents must implement them as described in
.
If the
<munder>
,
<mover>
or
<munderover>
elements do not have their
computed
display
property equal to math
then they are laid out according to the CSS specification where
the corresponding value is described.
Otherwise, the layout below is performed.
<munder>
,
<mover>
, <munderover>
If the <munder>
element
has less or more than two inflow children, its layout algorithm
is the same as the <mrow>
element.
Otherwise, the first inflow child is called the
base and the second inflow child is called the
underscript.
If the <mover>
element
has less or more than two inflow children, its layout algorithm
is the same as the <mrow>
element.
Otherwise, the first inflow child is called the
base and the second inflow child is called the
overscript.
If the <munderover>
element
has less or more than three inflow children, its layout algorithm
is the same as the <mrow>
element.
Otherwise, the first inflow child is called the
base, the second inflow child
is called the underscript
and its third inflow child is called
the overscript.
If the base is an
embellished operator with the
movablelimits
property
then the underscript and overscript are actually
drawn as subscript and superscript positions.
Then <mover>
, <mover>
and
<munderover>
layout algorithms are respectively
the same as the ones described for
<msub>
, <msup>
and
<msubsup>
in
,
and
.
Otherwise, the
<mover>
, <mover>
and
<munderover>
layout algorithms are respectively
described in
,
and
The algorithm for stretching operators along the inline axis is as follows.
L_{ToStretch}
containing
embellished operators with
a stretchy property and inline stretch axis
and a second list L_{NotToStretch}
.
L_{NotToStretch}
.
If L_{ToStretch}
is empty then stop.
If L_{NotToStretch}
is empty, perform
layout without any stretch size constraint on
all the items of L_{ToStretch}
.
T
to
the maximum inline size of the
margin boxes of child boxes that have been laid out in the
previous step.
L_{ToStretch}
with inline stretch size constraint T
.
The <munder>
element is laid out as shown on
.
LargeOpItalicCorrection
is the italic correction of the base
if it is an embellished operator with
the largeop
property and 0 otherwise.
The mincontent (respectively maxcontent) inline sizes of the content are calculated like the inline size of the content below but replacing the inline sizes of the base's margin box and underscript's margin box with the mincontent (respectively maxcontent) inline sizes of the base's margin box and underscript's margin box.
The inflow children are laid out using the algorithm for stretching operators along the inline axis.
The inline size of the content is calculated by determining the absolute difference between:
LargeOpItalicCorrection
.LargeOpItalicCorrection
.
If m is the minimum calculated in the second item above then the
inline offset
of the base is −m − half the inline size of the base's margin box.
The inline offset of the underscript is
−m − half the inline size of the underscript's margin box −
half LargeOpItalicCorrection
.
Parameters
UnderShift
and UnderExtraDescender
are determined by considering three cases in the following order:
The base is an
embellished operator with the
largeop
property.
UnderShift
is the maximum of
UnderExtraDescender
is 0.
The base is an
embellished operator with the
stretchy
property
and stretch axis inline.
UnderShift
is the maximum of:
UnderExtraDescender
is 0.
UnderShift
is equal to UnderbarVerticalGap
if the underscript is not an accent and to zero otherwise.
UnderExtraAscender
is
UnderbarExtraDescender.
The (ink) lineascent of the content is the maximum between:
UnderShift
.The (ink) linedescent of the content is the maximum between:
UnderShift
+ UnderExtraAscender
(this last term is ignored in the ink case).
The baseline of the base is aligned with the baseline.
The baseline of the underscript is shifted away from the baseline
and towards the lineunder by a distance equal to
the ink linedescent of the base's margin box
+ UnderShift
.
The <mover>
element is laid out as shown on
.
LargeOpItalicCorrection
is the italic correction of the base
if it is an embellished operator with
the largeop
property and 0 otherwise.
The mincontent (respectively maxcontent) inline sizes of the content are calculated like the inline size of the content below but replacing the inline sizes of the base's margin box and underscript's margin box with the mincontent (respectively maxcontent) inline sizes of the base's margin box and underscript's margin box.
The inflow children are laid out using the algorithm for stretching operators along the inline axis.
The TopAccentAttachment
is the
top accent attachment of the overscript or
half the inline size of the overscript's margin box
if it is undefined.
The inline size of the content is calculated by applying the algorithm for stretching operators along the inline axis for layout and determining the absolute difference between:
TopAccentAttachment
+
half LargeOpItalicCorrection
.TopAccentAttachment
+
half LargeOpItalicCorrection
.
If m is the minimum calculated in the second item above then the
inline offset
of the base is −m − half the inline size of the base's margin.
The inline offset of the overscript is
−m − half the inline size of the overscript's margin box +
half LargeOpItalicCorrection
.
Parameters
OverShift
and OverExtraDescender
are determined by considering three cases in the following order:
The base is an
embellished operator with the
largeop
property.
OverShift
is the maximum of
OverExtraAscender
is 0.
The base is an
embellished operator with the
stretchy
property and
stretch axis inline.
OverShift
is the maximum of:
OverExtraDescender
is 0.
Otherwise, OverShift
is equal to
OverExtraAscender
is OverbarExtraAscender.
The (ink) lineascent of the content is the maximum between:
OverShift
+ OverExtraAscender
(this last term is ignored in the ink case).The (ink) linedescent of the content is the maximum between:
OverShift
.
The baseline of the base is aligned with the baseline.
The baseline of the overscript is shifted away from the baseline
and towards the lineover by a distance equal to
the ink lineover of the base + OverShift
.
The general layout of <munderover>
is shown on
. The
LargeOpItalicCorrection
,
UnderShift
,
UnderExtraDescender
,
OverShift
,
OverExtraDescender
parameters
are calculated the same as in
and
.
The mincontent inline size, maxcontent inline size and inline size of the 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 and . The inline offsets of the base, underscript and overscript are calculated as in these sections but using the new minimum m (minimum of the corresponding minima).
Like in these sections, the inflow children are laid out using the algorithm for stretching operators along the inline axis.
The (ink) lineascent and (ink) linedescent of the content are also calculated by taking the extremum value of the extrema calculated in and .
Finally, the baselines of the base, undescript and overscript are calculated as in sections and .
When the underscript (respectively overscript) is an empty box, the base and overscript (respectively underscript) are laid out similarly to (respectively ) 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.
<mmultiscripts>
Presubscripts and tensor notations are represented
the <mmultiscripts>
with hints given by the
<mprescripts>
(to distinguish postscripts and prescripts)
and
<none>
elements
(to indicate empty scripts).
These element accept the attributes described in
.
If the
<mmultiscripts>
,
<mprescripts>
or
<none>
elements do not have their
computed
display
property equal to math
then they are laid out according to the CSS specification where
the corresponding value is described.
Otherwise, the layout below is performed.
The empty
<mprescripts>
and <none>
elements are laid out as an <mrow>
element.
A valid <mmultiscripts>
element contains the
following inflow children:
<mprescripts>
element.
<mprescripts>
element.
These scripts form a (possibly empty) list of
subscript/superscript pairs.
<mprescripts>
element and
an even number of inflow children called
prescripts, none of them being a
<mprescripts>
element.
These scripts form a (possibly empty) list of
subscript/superscript pairs.
If an <mmultiscripts>
element is not valid then
it is laid out the same as the
<mrow>
element.
Otherwise the layout algorithm is explained below.
<none>
element is preserved for backward
compatibility reasons but is actually not taken into account
in the layout algorithm.
The <mmultiscripts>
element is laid out as
shown on .
For each postscript pair, the ItalicCorrection
LargeOpItalicCorrection
are defined as
in
and .
The mincontent (respectively maxcontent) inline size of the content is calculated the same as the inline size of the content below, but replacing "inline size" with "mincontent inline size" (respectively "maxcontent inline size") for the base's margin box and scripts's margin boxes.
If there is an inline stretch size constraint or a block stretch size constraint the 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 content is calculated with the following algorithm:
inlineoffset
to 0.
For each prescript pair, increment
inlineoffset
by SpaceAfterScript + the
maximum of
inlineoffset
by the inline size of the
base's margin box and
set inlinesize
to inlineoffset
.
For each postscript pair, modify
inlinesize
to be at least:
LargeOpItalicCorrection
.
ItalicCorrection
.
Increment inlineoffset
to the maximum of:
Increment inlineoffset
by
SpaceAfterScript.
inlinesize
SubShift
(respectively SuperShift
)
is calculated by taking the maximum of all subshifts
(respectively supershifts) of each
subscript/superscript pair as described in
.
The (ink) lineascent of the content is calculated
by taking the maximum of all the (ink) lineascent
of each subscript/superscript pair as described in
but using the SubShift
and
SuperShift
values calculated above.
The (ink) linedescent of the content is calculated
by taking the maximum of all the (ink) linedescent
of each subscript/superscript pair as described in
but using the SubShift
and
SuperShift
values calculated above.
Finally, the placement of the inflow children is performed using the following algorithm:
inlineoffset
to 0.For each prescript pair:
inlineoffset
by
SpaceAfterScript.
pairinlinesize
to the maximum of
inlineoffset
+ pairinlinesize
− the inline size of the subscript's margin box.
inlineoffset
+ pairinlinesize
− the inline size of the superscript's margin box.
SubShift
(respectively SuperShift
)
towards the lineunder (respectively lineover).
inlineoffset
by
pairinlinesize
.
<mprescript>
boxes
at inline offsets
inlineoffset
and with their baselines
aligned with the baseline.
For each postscript pair:
pairinlinesize
to the maximum of
inlineoffset
− LargeOpItalicCorrection
.
inlineoffset
+ ItalicCorrection
.
SubShift
(respectively SuperShift
)
towards the lineunder (respectively lineover).
inlineoffset
by
pairinlinesize
inlineoffset
by
SpaceAfterScript.
An <mmultiscripts>
with only one
postscript pair is laid out the same as a
<msubsup>
with the same inflow 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 or <none>
scripts in a special
way.
For all MathML elements used for scripts and limits schemata,
the rule of thumb is to set
displaystyle
to false
and to increment scriptlevel
in all child
elements but the first one.
However, when an overscript (respectively underscript)
has an accent
(respectively accentunder
)
attribute that is caseinsensitive match
to "true"
then
the scriptlevel
is not incremented.
The must contain the following style in order to implement this behavior:
accent
property.
<mprescript>
is empty.
Hence the CSS rules essentially performs automatic displaystyle and
scriptlevel changes for the scripts.
Matrices, arrays and other tablelike mathematical notation are marked up
using
<mtable>
<mtr>
<mtd>
elements. These elements are similar to the
<table>
,
<tr>
and
<td>
elements of [[HTML]].
<mtable>
The <mtable>
is laid out as an
inlinetable
and sets
displaystyle
to false
. The
user agent stylesheet must contain
the following rules in order to implement these properties:
The <mtable>
accepts the attributes described
in as well as the following
attribute:
The frame attribute, if present, must be a caseinsensitive match
to one of none
, solid
or
dashed
. The user agent
stylesheet must contain the following rules in order to implement
that attribute:
The mtable
element is as a CSS
table
and the mincontent/maxcontent inline sizes,
inline size, block size, first/last baseline sets are determined
accordingly.
The math axis is aligned with the center of the table.
<mtr>
The <mtr>
is laid out as
tablerow
. The
user agent stylesheet must contain
the following rules in order to implement that behavior:
<mtd>
The <mtd>
is laid out as
a tablecell
with content centered in the cell and
a default padding. The
user agent stylesheet must contain
the following rules:
The <mtr>
accepts the attributes described
in as well as the following attributes:
The columnspan
(respectively
rowspan
) attribute has the same
syntax and semantic as the
<colspan>
(respectively
<rowspan>
)
attribute on the <td>
element from [[HTML]].
columnspan
as in [[MathML3]] and not
colspan
as in [[HTML]].
Historically, the
<maction>
element provides a mechanism
for binding actions to expressions.
The <maction>
element accepts the attributes described
in as well as the following
attributes:
actiontype
selection
The actiontype and selection attributes are
not taken into account in the present specification but may be used
by authors to implement custom actions on the
<maction>
element.
The layout algorithm of the <maction>
element
the same as the <mrow>
element.
The user agent stylesheet
must contain the following rules in order to hide all but
its first child element,
which is the default behavior for the legacy actiontype
values:
<maction>
is implemented for compatibility with full MathML. Authors whose only target is MathML Core are encouraged to use CSS for styling.
The
<semantics>
element is the container element that associates
annotations with a MathML expression. Typically, the
<semantics>
element has as its first child element
a MathML expression to be annotated while subsequent child elements
represent
text annotations within an <annotation>
element, or more complex markup annotations within
an <annotationxml>
element.
The <semantics>
element accepts the attributes
described in . Its layout algorithm
is the same as the <mrow>
element.
The user agent stylesheet
must contain the following rule in order to only render the annotated
MathML expression:
The <annotationxml>
and
<annotation>
element accepts the attributes
described in as well as the
following attribute:
encoding
The encoding attribute is not taken into account in the present specification but it is intended to distinguish annotations for HTML integration point, clipboard copy, alternative rendering etc
The layout algorithm of the <annotationxml>
and <annotation>
element is the same as the <mtext>
element.
/* Hide the annotated child. */ semantics > :firstchild { display: none; } /* Show all text annotations. */ semantics > annotation { display: inline; } /* Show all HTML annotations. */ semantics > annotationxml[encoding="text/html" i], semantics > annotationxml[encoding="application/xhtml+xml" i] { display: inlineblock; }
display: math
valuemathauto
? mathml?
...The display
property
from
is extended with a new math
value:
<displayold>  math
For the <math>
,
<mtable>
,
<mtr>
and
<mtd>
elements, the
math
value respectively computes to
inline
,
inlinetable
,
tablerow
and tablecell
.
Other MathML elements with display: math
will control
box generation and layout according to their tag name, as described
in the relevant sections.
For nonMathML elements, the math
value computes to
none
.
display: math
value provides a default
layout for MathML elements while at the same time allowing authors
to override it with either native display values or
custom values.
texttransform
valuesThe texttransform
property
from
is extended with new values:
<texttransformold>  mathauto  mathbold  mathitalic  mathbolditalic  mathdoublestruck  mathboldfraktur  mathscript  mathboldscript  mathfraktur  mathsansserif  mathboldsansserif  mathsansserifitalic  mathsansserifbolditalic  mathmonospace  mathinitial  mathtailed  mathlooped  mathstretched
On text nodes containing a unique character, mathauto
has
the same effect as mathitalic
, otherwise it has no effects.
For the
mathbold
,
mathitalic
,
mathbolditalic
,
mathdoublestruck
,
mathboldfraktur
,
mathscript
,
mathboldscript
,
mathfraktur
,
mathsansserif
,
mathboldsansserif
,
mathsansserifitalic
,
mathsansserifbolditalic
,
mathmonospace
,
mathinitial
,
mathtailed
,
mathlooped
and
mathstretched
values, the transformed text is
obtained by performing conversion of each character according to
the corresponding
bold,
italic,
bolditalic,
doublestruck,
boldfraktur,
script,
boldscript,
fraktur,
sansserif,
boldsansserif,
sansserifitalic,
sansserifbolditalic,
monospace,
initial,
tailed,
looped,
stretched tables.
User agents may decide to rely on italic, bold and bolditalic
fontlevel properties when available fonts lack the proper glyphs to
perform mathauto
, mathitalic
,
mathbold
, mathbolditalic
characterlevel
transforms.
mathstyle
propertyName: 
mathstyle


Value:  display  inline 
Initial:  inline 
Applies to:  All elements 
Inherited:  yes 
Percentages:  n/a 
Media:  visual 
Computed value:  specified keyword 
Canonical order:  n/a 
Animation type:  not animatable 
If the value of mathstyle
is inline
, the math
layout on descendants should try to minimize the
logical height.
This includes how
fontsize
is changed when mathscriptlevel
is
auto
as well
miscelleanous layout rules described in details in
.
If the value of mathstyle
is display
, the math
layout should not take such constraints into consideration.
mathscriptlevel
propertyName: 
mathscriptlevel


Value:  auto  add(<integer>)  <integer> 
Initial:  0 
Applies to:  All elements 
Inherited:  yes 
Percentages:  n/a 
Media:  visual 
Computed value:  see individual properties 
Canonical order:  n/a 
Animation type:  not animatable 
If the specified value of mathscriptlevel
is
auto
and the inherited value of mathstyle
is
display
then the computed value of
mathscriptlevel
is the inherited value.
If the specified value of mathscriptlevel
is
auto
and the inherited value of mathstyle
is
inline
then the computed value of
mathscriptlevel
is the inherited value plus one.
If the specified value of mathscriptlevel
is of the form
add(<integer>)
then the computed value of
mathscriptlevel
is the inherited value plus the specified
integer.
If the specified value of mathscriptlevel
is of the form
<integer>
then the computed value of
mathscriptlevel
is set to the specified integer.
If
fontsize
is specified or if the specified value of
mathscriptlevel
is initial
then
mathscriptlevel
does not affect the computed value of
fontsize
. Otherwise, the computed value of
fontsize
is obtained by multiplying the inherited value of
fontsize
by a nonzero scale factor calculated by the
following procedure:
mathscriptlevel
, B the computed
mathscriptlevel
, C be 0.71 and S be 1.0InvertScaleFactor
to true.InvertScaleFactor
to false.InvertScaleFactor
is false and 1/S otherwise.MATH
table
This chapter describes features provided by MATH
table
of an OpenType font [[OPENFONTFORMAT]]. Throughout this chapter,
a Clike notation
Table.Subtable1[index].Subtable2.Parameter
is used to
denote OpenType parameters.
Such parameters may not be available (e.g. if the font lack one of the
subtable, has an invalid offset, etc) and so fallback options are
provided.
OpenType values expressed in design units (perhaps indirectly via a
MathValueRecord
entry) are scaled to appropriate values
for layout purpose, taking into account
head.unitsPerEm
, CSS
fontsize
or zoom level.
MathConstants
)These are global layout constants for a given mathematical font:
MATH.MathConstants.scriptPercentScaleDown / 100
or
0.71 if MATH.MathConstants.scriptPercentScaleDown
is
null or not available.
MATH.MathConstants.scriptScriptPercentScaleDown / 100
or
0.5041 if
MATH.MathConstants.scriptScriptPercentScaleDown
is
null or not available.
MATH.MathConstants.displayOperatorMinHeight
or ?? if the constant is not available.MATH.MathConstants.axisHeight
or ?? if the constant is not available.MATH.MathConstants.accentBaseHeight
or ?? if the constant is not available.MATH.MathConstants.subscriptShiftDown
or ?? if the constant is not available.MATH.MathConstants.subscriptTopMax
or ?? if the constant is not available.MATH.MathConstants.subscriptBaselineDropMin
or ?? if the constant is not available.MATH.MathConstants.superscriptShiftUp
or ?? if the constant is not available.MATH.MathConstants.superscriptShiftUpCramped
or ?? if the constant is not available.MATH.MathConstants.superscriptBottomMin
or ?? if the constant is not available.MATH.MathConstants.superscriptBaselineDropMax
or ?? if the constant is not available.MATH.MathConstants.subSuperscriptGapMin
or ?? if the constant is not available.MATH.MathConstants.superscriptBottomMaxWithSubscript
or ?? if the constant is not available.MATH.MathConstants.spaceAfterScript
or ?? if the constant is not available.MATH.MathConstants.upperLimitGapMin
or ?? if the constant is not available.MATH.MathConstants.upperLimitBaselineRiseMin
or ?? if the constant is not available.MATH.MathConstants.lowerLimitGapMin
or ?? if the constant is not available.MATH.MathConstants.lowerLimitBaselineDropMin
or ?? if the constant is not available.MATH.MathConstants.stackTopShiftUp
or ?? if the constant is not available.MATH.MathConstants.stackTopDisplayStyleShiftUp
or ?? if the constant is not available.MATH.MathConstants.stackBottomShiftDown
or ?? if the constant is not available.MATH.MathConstants.stackBottomDisplayStyleShiftDown
or ?? if the constant is not available.MATH.MathConstants.stackGapMin
or ?? if the constant is not available.MATH.MathConstants.stackDisplayStyleGapMin
or ?? if the constant is not available.MATH.MathConstants.stretchStackTopShiftUp
or ?? if the constant is not available.MATH.MathConstants.stretchStackBottomShiftDown
or ?? if the constant is not available.MATH.MathConstants.stretchStackGapAboveMin
or ?? if the constant is not available.MATH.MathConstants.stretchStackGapBelowMin
or ?? if the constant is not available.MATH.MathConstants.fractionNumeratorShiftUp
or ?? if the constant is not available.MATH.MathConstants.fractionNumeratorDisplayStyleShiftUp
or ?? if the constant is not available.MATH.MathConstants.fractionDenominatorShiftDown
or ?? if the constant is not available.MATH.MathConstants.fractionDenominatorDisplayStyleShiftDown
or ?? if the constant is not available.MATH.MathConstants.fractionNumeratorGapMin
or ?? if the constant is not available.MATH.MathConstants.fractionNumDisplayStyleGapMin
or ?? if the constant is not available.MATH.MathConstants.fractionRuleThickness
or ?? if the constant is not available.MATH.MathConstants.fractionDenominatorGapMin
or ?? if the constant is not available.MATH.MathConstants.fractionDenomDisplayStyleGapMin
or ?? if the constant is not available.MATH.MathConstants.overbarVerticalGap
or ?? if the constant is not available.MATH.MathConstants.overbarRuleThickness
or ?? if the constant is not available.MATH.MathConstants.overbarExtraAscender
or ?? if the constant is not available.MATH.MathConstants.underbarVerticalGap
or ?? if the constant is not available.MATH.MathConstants.underbarRuleThickness
or ?? if the constant is not available.MATH.MathConstants.underbarExtraDescender
or ?? if the constant is not available.MATH.MathConstants.radicalVerticalGap
or ?? if the constant is not available.MATH.MathConstants.radicalDisplayStyleVerticalGap
or ?? if the constant is not available.MATH.MathConstants.radicalRuleThickness
or ?? if the constant is not available.MATH.MathConstants.radicalExtraAscender
or ?? if the constant is not available.MATH.MathConstants.radicalKernBeforeDegree
or 5/18em if the constant is not available.MATH.MathConstants.radicalKernAfterDegree
or −10/18em if the constant is not available.MATH.MathConstants.radicalDegreeBottomRaisePercent / 100.0
or 0.6 if the constant is not available.MathGlyphInfo
)These are perglyph tables for a given mathematical font:
MATH.MathGlyphInfo.MathItalicsCorrectionInfo
of italics correction values. Use the corresponding value in
MATH.MathGlyphInfo.MathItalicsCorrectionInfo.italicsCorrection
if there is one for the requested glyph or
or 0
otherwise.
MATH.MathGlyphInfo.MathTopAccentAttachment
of positioning top math accents along the inline axis.
Use the corresponding value in
MATH.MathGlyphInfo.MathTopAccentAttachment.topAccentAttachment
if there is one for the requested glyph or
or half the advance width of the glyph otherwise.
MathVariants
)
This section describes how to handle stretchy glyphs of arbitrary
size using the MATH.MathVariants
table.
GlyphAssembly
tableThis section is based on [[?OPENTYPEMATHINHARFBUZZ]]. For convenience, the following definitions are used:
MATH.MathVariant.minConnectorOverlap
.
GlyphPartRecord
is an extender
if and only if
GlyphPartRecord.partFlags
has the
fExtender
flag set.
GlyphAssembly
is horizontal
if it is obtained from
MathVariant.horizGlyphConstructionOffsets
.
Otherwise it is vertical (and obtained from
MathVariant.vertGlyphConstructionOffsets
).
GlyphAssembly
table,
N_{Ext} (respectively
N_{NonExt}) is the number of extenders
(respectively nonextenders) in
GlyphAssembly.partRecords
.
GlyphAssembly
table,
S_{Ext} (respectively
S_{NonExt}) is the sum of
GlyphPartRecord.fullAdvance
for all extenders (respectively nonextenders) in
GlyphAssembly.partRecords
.
User agents must treat the GlyphAssembly
as invalid
if the following conditions are not satisfied:
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
.
AssembySize(o, r) is the stretch size of a glyph assembly built by repeating each extender r times and using the same overlap value o between each glyph. It is equal to S_{NonExt} − o (N_{NonExt} − 1) + r (S_{Ext} − o N_{Ext}) or, equivalently, AssembySize(o, r) = S_{NonExt} + r S_{Ext} − o (N_{NonExt} + r N_{Ext} − 1).
r_{min} is the minimal number of repetitions needed to obtain an assembly size of size at least T. It is the maximum between 0 and the ceiling of (T − S_{NonExt} − o_{min} (N_{NonExt} − 1)) / (S_{Ext} − o_{min} N_{Ext}).
o_{max} is the maximum overlap possible to build an assembly of size at least T by repeating each extender r_{min} times. N = N_{NonExt} + r_{min} N_{Ext} is the number of glyphs in such an assembly. If N ≤ 1, then the overlap is irrelevant, so o_{max} is defined to be o_{min}. Otherwise, o_{max} is defined to be the minimum of:
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:
GlyphAssembly
is horizontal,
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.
GlyphAssembly
is vertical,
the width is glyph assembly stretch size
for a given target size T
while
the ascent (respectively descent) is the
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.
T
.
The shaping of the glyph assembly
at position P
is performed with the following
algorithm:
(x, y)
to P
if
RepetitionCounter
to 0 and
PartIndex
to 1.
RepetitionCounter
is 0, then
PartIndex
.PartIndex
is
GlyphAssembly.partCount
then stop.Part
to
GlyphAssembly.partRecords[PartIndex]
.
Set RepetitionCounter
to
r_{min} if
Part
is an extender and to 1 otherwise.
Part.glyphID
so that its (left, baseline) coordinates
are at position (x, y)
.
Set x
to
x + Part.fullAdvance −
o_{max}
Part.glyphID
so that its (left, bottom) coordinates
are at position (x, y)
.
Set y
to
y − Part.fullAdvance +
o_{max}
RepetitionCounter
.The preferred inline size of a glyph stretched along the block axis is calculated using the following algorithm:
S
to the glyph's advance width.
MathGlyphConstruction
table
in the MathVariants.vertGlyphConstructionOffsets
table for the given glyph:
MathGlyphVariantRecord
in
MathGlyphConstruction.mathGlyphVariantRecord
,
ensure that S
is at least
the advance width of the glyph of id
MathGlyphVariantRecord.variantGlyph
.
GlyphAssembly
subtable,
then ensure
that S
is at least the
glyph assembly width.
S
.
The algorithm to calculate the
box metrics of a stretchy glyph
stretched to inline (respectively block) dimension
T
is the following:
B
to glyph's advanced width, ascent and
descent.
If the glyph's advance width
(respectively height) is at least T
then return B
.
MathGlyphConstruction
table
in the MathVariants.horizGlyphConstructionOffsets
table (respectively
MathVariants.vertGlyphConstructionOffsets
table)
for the given glyph:
MathGlyphVariantRecord
in
MathGlyphConstruction.mathGlyphVariantRecord
:
B
to the advanced width, ascent and
descent of the glyph of id
MathGlyphVariantRecord.variantGlyph
.
MathGlyphVariantRecord.advanceMeasurement
is at least T
then return
B
.
GlyphAssembly
subtable
then set B
to the
glyph assembly width,
glyph assembly ascent
and glyph assembly descent
for the target size T
.
B
.The algorithm to
shape a stretchy glyph to inline
(respectively block) dimension T
at a position
P
is the following:
T
then draw the glyph so that its (left, baseline) coordinates
are at position P
and exit.
MathGlyphConstruction
table
in the MathVariants.horizGlyphConstructionOffsets
table (respectively
MathVariants.vertGlyphConstructionOffsets
table)
for the given glyph:
MathGlyphVariantRecord
in
MathGlyphConstruction.mathGlyphVariantRecord
,
if
MathGlyphVariantRecord.advanceMeasurement
is at least T
then draw the glyph
so that its (left, baseline) coordinates
are at position P
and exit.
GlyphAssembly
subtable
then perform
shaping of the glyph assembly
at position P
and exit.
@namespace url(http://www.w3.org/1998/Math/MathML); /* Default display */ /* Links */ /* The <math> element */ /* <mrow>like elements */ /* Tables */ /* Fractions */ /* Other rules for scriptlevel and displaystyle */
Users agent must use a dictionary of rendering properties for MathML operators. The dictionary must include at least the entries of the table below.
The dictionary is indexed by 'Content' and 'Form' columns together. describes how to determine these values for a given operator. The 'Rendering' and 'Unicode' columns are provided for convenience, but they are just alternative to the 'Content' column.
The 'Priority' column is significant for the proper grouping of
subexpressions using <mrow>
. This is especially
relevant to the automatic generation of MathML by conversion from
other formats for displayed mathematics, such as T_{E}X,
which do not always specify how subexpressions nest.
However, it does not affect the rendering described in this
specification and so is not needed for implementing it in user agents.
The length valued attributes lspace
and
rspace
are given here as numeric values ranging
from 0 to 7 in order to save space in the table. They must be
interpreted as multiples of 1/18em i.e.
0
,
0.05555555555555555em
,
0.1111111111111111em
,
0.16666666666666666em
,
0.2222222222222222em
,
0.2777777777777778em
,
0.3333333333333333em
,
0.3888888888888889em
respectively.
Boolean valued attributes
fence
,
separator
,
stretchy
,
symmetric
,
largeop
,
movablelimits
,
accent
are
specified together in the final 'Properties' column by listing the
attribute name if its value should be set to true by the dictionary.
The default stretch axis for all characters is block. However, the stretch axis for the following characters is inline:
The following table gives mappings between spacing and non spacing characters when used in MathML accent constructs.
The following table provide fallback that user agents must use for
stretching a given base character when the font does not
provide a MATH.MathVariants
table.
The algorithms of
works the same except with some adjustments:
MathVariants.horizGlyphConstructionOffsets[]
item ;
if it is vertical it corresponds to
a MathVariants.vertGlyphConstructionOffsets[]
item.
MathGlyphConstruction.mathGlyphVariantRecord
is
always empty.
MathVariants.minConnectorOverlap
,
GlyphPartRecord.startConnectorLength
and
GlyphPartRecord.endConnectorLength
are treated as 0.
MathGlyphConstruction.GlyphAssembly.partRecords
is built
from each table row as follows:
texttransform
Mappingsboldscript
mappingsbolditalic
mappingstailed
mappingsbold
mappingsfraktur
mappingsscript
mappingsmonospace
mappingsinitial
mappingssansserif
mappingsdoublestruck
mappingslooped
mappingsstretched
mappingsitalic
mappingsboldfraktur
mappingssansserifbolditalic
mappingssansserifitalic
mappingsboldsansserif
mappingsConformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.
All of the text of this specification is normative except sections explicitly marked as nonnormative, examples, and notes. [[RFC2119]].
Examples in this specification are introduced with the words
“for example” or are set apart from the normative text with
class="example"
, like this:
This is an example of an informative example.
Informative notes begin with the word “Note” and are set apart from
the normative text with class="note"
, like this:
Note, this is an informative note.
Advisements are normative sections styled to evoke special attention
and are set apart from other normative text with
<strong class="advisement">
, like this:
UAs MUST provide an accessible alternative.