3 Presentation Markup

Mathematical Markup Language (MathML) Version 2.0
2 MathML Fundamentals
3 Presentation Markup
3.1 Introduction
   3.1.1 What Presentation Elements Represent
   3.1.2 Terminology Used In This Chapter
   3.1.3 Required Arguments
   3.1.4 Elements with Special Behaviors
   3.1.5 Summary of Presentation Elements
3.2 Token Elements
   3.2.1 Attributes common to token elements
   3.2.2 Identifier (mi)
   3.2.3 Number (mn)
   3.2.4 Operator, Fence, Separator or Accent (mo)
   3.2.5 Text (mtext)
   3.2.6 Space (mspace)
   3.2.7 String Literal (ms)
   3.2.8 Refering to non-ASCII characters (mchar)
   3.2.9 Adding new character glyphs to MathML (mglyph)
3.3 General Layout Schemata
   3.3.1 Horizontally Group Sub-Expressions (mrow)
   3.3.2 Fractions (mfrac)
   3.3.3 Radicals (msqrt, mroot)
   3.3.4 Style Change (mstyle)
   3.3.5 Error Message (merror)
   3.3.6 Adjust Space Around Content (mpadded)
   3.3.7 Making Content Invisible (mphantom)
   3.3.8 Content Inside Pair of Fences (mfenced)
   3.3.9 Enclose Content Inside Notation (menclose)
3.4 Script and Limit Schemata
   3.4.1 Subscript (msub)
   3.4.2 Superscript (msup)
   3.4.3 Subscript-superscript Pair (msubsup)
   3.4.4 Underscript (munder)
   3.4.5 Overscript (mover)
   3.4.6 Underscript-overscript Pair (munderover)
   3.4.7 Prescripts and Tensor Indices (mmultiscripts)
3.5 Tables and Matrices
   3.5.1 Table or Matrix (mtable)
   3.5.2 Row in Table or Matrix (mtr)
   3.5.3 Labeled Row in Table or Matrix (mlabeledtr)
   3.5.4 Entry in Table or Matrix (mtd)
   3.5.5 Alignment Markers
3.6 Enlivening Expressions
   3.6.1 Bind Action to Sub-Expression (maction)
4 Content Markup

3.1 Introduction

This chapter specifies the `presentation' elements of MathML, which can be used to describe the layout structure of mathematical notation.

3.1.1 What Presentation Elements Represent

Presentation elements correspond to the `constructors' of traditional mathematical notation - that is, to the basic kinds of symbols and expression-building structures out of which any particular piece of traditional mathematical notation is built. Because of the importance of traditional visual notation, the descriptions of the notational constructs the elements represent are usually given here in visual terms. However, the elements are medium-independent in the sense that they have been designed to contain enough information for good spoken renderings as well. Some attributes of these elements may make sense only for visual media, but most attributes can be treated in an analogous way in audio as well (for example, by a correspondence between time duration and horizontal extent).

MathML presentation elements only suggest (i.e. do not require) specific ways of rendering in order to allow for medium-dependent rendering and for individual preferences of style. This specification describes suggested visual rendering rules in some detail, but a particular MathML renderer is free to use its own rules as long as its renderings are intelligible.

The presentation elements are meant to express the syntactic structure of mathematical notation in much the same way as titles, sections, and paragraphs capture the higher level syntactic structure of a textual document. Because of this, for example, a single row of identifiers and operators, such as `x + a / b', will often be represented not just by one mrow element (which renders as a horizontal row of its arguments), but by multiple nested mrow elements corresponding to the nested sub-expressions of which one mathematical expression is composed - in this case,

<mrow>
  <mi> x </mi>
  <mo> + </mo>
  <mrow>
     <mi> a </mi>
     <mo> / </mo>
     <mi> b </mi>
  </mrow>
</mrow>

Similarly, superscripts are attached not just to the preceding character, but to the full expression constituting their base. This structure allows for better-quality rendering of mathematics, especially when details of the rendering environment such as display widths are not known to the document author; it also greatly eases automatic interpretation of the mathematical structures being represented.

Certain extended characters, represented by entity references, are used to name operators or identifiers that in traditional notation render the same as other symbols, such as &DifferentialD;, &ExponentialE;, or &ImaginaryI;, or operators that usually render invisibly, such as ⁢, ⁡, or ⁣. These are distinct notational symbols or objects, as evidenced by their distinct spoken renderings and in some cases by their effects on linebreaking and spacing in visual rendering, and as such should be represented by the appropriate specific entity references. For example, the expression represented visually as `f(x)' would usually be spoken in English as `f of x' rather than just `f x'; this is expressible in MathML by the use of the ⁡ operator after the `f', which (in this case) can be aurally rendered as `of'.

The complete list of MathML entities is described in chapter 6 [Entities, Characters and Fonts].

3.1.2 Terminology Used In This Chapter

It is strongly recommended that, before reading the present chapter, one read section 2.3 [MathML Syntax and Grammar] on MathML syntax and grammar, which contains important information on MathML notations and conventions. In particular, in this chapter it is assumed that the reader has an understanding of basic XML terminology described in section 2.3.1 [An XML Syntax Primer], and the attribute value notations and conventions described in section 2.3.3 [MathML Attribute Values].

The remainder of this section introduces MathML-specific terminology and conventions used in this chapter.

3.1.2.1 Types of presentation elements

The presentation elements are divided into two classes. Token elements represent individual symbols, names, numbers, labels, etcetera. In general, tokens can have only characters and mchar elements as content. The only exceptions are the vertical alignment element malignmark, and entity references. (Note, however, that entity references are deprecated in favor of the mchar element in MathML 2.0 .) Layout schemata build expressions out of parts, and can have only elements as content (except for whitespace, which they ignore). There are also a few empty elements used only in conjunction with certain layout schemata.

All individual `symbols' in a mathematical expression should be represented by MathML token elements. The primary MathML token element types are identifiers (e.g. variables or function names), numbers, and operators (including fences, such as parentheses, and separators, such as commas). There are also token elements for representing text or whitespace that has more aesthetic than mathematical significance, and for representing `string literals' for compatibility with computer algebra systems. Note that although a token element represents a single meaningful `symbol' (name, number, label, mathematical symbol, etcetera), such symbols may be comprised of more than one character. For example sin and 24 are represented by the single tokens <mi>sin</mi> and <mn>24</mn> respectively.

In traditional mathematical notation, expressions are recursively constructed out of smaller expressions, and ultimately out of single symbols, with the parts grouped and positioned using one of a small set of notational structures, which can be thought of as `expression constructors'. In MathML, expressions are constructed in the same way, with the layout schemata playing the role of the expression constructors. The layout schemata specify the way in which sub-expressions are built into larger expressions. The terminology derives from the fact that each layout schema corresponds to a different way of `laying out' its sub-expressions to form a larger expression in traditional mathematical typesetting.

3.1.2.2 Terminology for other classes of elements and their relationships

The terminology used in this chapter for special classes of elements, and for relationships between elements, is as follows: The presentation elements are the MathML elements defined in this chapter. These elements are listed in section 3.1.5 [Summary of Presentation Elements]. The content elements are the MathML elements defined in chapter 4 [Content Markup]. The content elements are listed in section 4.4 [The Content Markup Elements].

A MathML expression is a single instance of any of the presentation elements with the exception of the empty elements none or mprescripts, or is a single instance of any of the content elements which are allowed as content of presentation elements (listed in section 5.2.4 [Content Markup Contained in Presentation Markup]). The intuition behind the definition of an expression is that it is an element with an unambigous rendering without some larger, enclosing construct. A sub-expression of an expression E is any MathML expression that is part of the content of E, whether directly or indirectly, i.e. whether it is a `child' of E or not.

Since layout schemata attach special meaning to the number and/or positions of their children, a child of a layout schema is also called an argument of that element. As a consequence of the above definitions, the content of a layout schema consists exactly of a sequence of zero or more nonoverlapping elements that are its arguments.

3.1.3 Required Arguments

Many of the elements described herein require a specific number of arguments (always 1, 2, or 3). In the detailed descriptions of element syntax given below, the number of required arguments is implicitly indicated by giving names for the arguments at various positions. A few elements have additional requirements on the number or type of arguments, which are described with the individual element. For example, some elements accept sequences of zero or more arguments - that is, they are allowed to occur with no arguments at all.

Note that MathML elements encoding rendered space do count as arguments of the elements they appear in. See section 3.2.6 [Space (mspace)] for a discussion of the proper use of such space-like elements.

3.1.3.1 Inferred `mrow`s

The elements listed in the following table as requiring 1* argument (msqrt, mstyle, merror, mpadded, mphantom, and mtd) actually accept any number of arguments. However, if the number of arguments is 0, or is more than 1, they treat their contents as a single inferred mrow formed from all their arguments.

For example,

<mtd>
</mtd>

is treated as if it were

<mtd>
  <mrow>
  </mrow>
</mtd>

and

<msqrt>
   <mo> - </mo>
   <mn> 1 </mn>
</msqrt>

is treated as if it were

<msqrt>
   <mrow>
      <mo> - </mo>
      <mn> 1 </mn>
   </mrow>
</msqrt>

This feature allows MathML data not to contain (and its authors to leave out) many mrow elements that would otherwise be necessary.

In the descriptions in this chapter of the above-listed elements' rendering behaviors, their content can be assumed to consist of exactly one expression, which may be an mrow element formed from their arguments in this manner. However, their argument counts are shown in the following table as 1*, since they are most naturally understood as acting on a single expression.

3.1.3.2 Table of argument requirements

For convenience, here is a table of each element's argument count requirements, and the roles of individual arguments when these are distinguished. An argument count of 1* indicates an inferred mrow as described above.

Element	Required argument count	Argument roles (when these differ by position)
`mrow`	0 or more
`mfrac`	2	numerator denominator
`msqrt`	1*
`mroot`	2	base index
`mstyle`	1*
`merror`	1*
`mpadded`	1*
`mphantom`	1*
`mfenced`	0 or more
`msub`	2	base subscript
`msup`	2	base superscript
`msubsup`	3	base subscript superscript
`munder`	2	base underscript
`mover`	2	base overscript
`munderover`	3	base underscript overscript
`mmultiscripts`	1 or more	base (subscript superscript)* [`<mprescripts/>` (presubscript presuperscript)*]
`mtable`	0 or more rows	0 or more `mtr` elements
`mtr`	0 or more table elements	0 or more `mtd` elements
`mtd`	1*
`maction`	1 or more	depend on `actiontype` attribute

3.1.4 Elements with Special Behaviors

Certain MathML presentation elements exhibit special behaviors in certain contexts. Such special behaviors are discussed in the detailed element descriptions below. However, for convenience, some of the most important classes of special behavior are listed here.

Certain elements are considered space-like; these are defined in section 3.2.6 [Space (mspace)]. This definition affects some of the suggested rendering rules for mo elements (section 3.2.4 [Operator, Fence, Separator or Accent (mo)]).

Certain elements, e.g. msup, are able to embellish operators that are their first argument. These elements are listed in section 3.2.4 [Operator, Fence, Separator or Accent (mo)], which precisely defines an `embellished operator' and explains how this affects the suggested rendering rules for stretchy operators.

Certain elements treat their arguments as the arguments of an `inferred mrow' if they are not given exactly one argument, as explained in section 3.1.3 [Required Arguments].

In MathML 1.x, the mtable element could infer mtr elements around its arguments, and the mtr element could infer mtd elements. In MathML 2.0, mtr and mtd elements must be explicit. However, for backward compatibility renderers may wish to continue supporting inferred mtr and mtd elements.

3.1.5 Summary of Presentation Elements

3.1.5.1 Token Elements

`mi`	identifier
`mn`	number
`mo`	operator, fence, or separator
`mtext`	text
`mspace`	space
`ms`	string literal
`mchar`	referring to non-ASCII characters
`mglyph`	adding new character glyphs to MathML

3.1.5.2 General Layout Schemata

`mrow`	group any number of sub-expressions horizontally
`mfrac`	form a fraction from two sub-expressions
`msqrt`	form a square root sign (radical without an index)
`mroot`	form a radical with specified index
`mstyle`	style change
`merror`	enclose a syntax error message from a preprocessor
`mpadded`	adjust space around content
`mphantom`	make content invisible but preserve its size
`mfenced`	surround content with a pair of fences

3.1.5.3 Script and Limit Schemata

`msub`	attach a subscript to a base
`msup`	attach a superscript to a base
`msubsup`	attach a subscript-superscript pair to a base
`munder`	attach an underscript to a base
`mover`	attach an overscript to a base
`munderover`	attach an underscript-overscript pair to a base
`mmultiscripts`	attach prescripts and tensor indices to a base

3.1.5.4 Tables and Matrices

`mtable`	table or matrix
`mtr`	row in a table or matrix
`mtd`	one entry in a table or matrix
`maligngroup` and `malignmark`	alignment markers

3.1.5.5 Enlivening Expressions

maction bind actions to a sub-expression

3.2 Token Elements

Token elements can contain any sequence of zero or more characters, or extended characters represented by entity references. In particular, tokens with empty content are allowed, and should typically render invisibly, with no width except for the normal extra spacing for that kind of token element. The allowed set of entity references for extended characters is given in chapter 6 [Entities, Characters and Fonts].

In MathML, characters and MathML entity references are only allowed to occur as part of the content of a token element. The only exception is whitespace between elements, which is ignored.

The malignmark element (see section 3.5.5 [Alignment Markers]) is the only element allowed in the content of tokens. It marks a place that can be vertically aligned with other objects, as explained in that section.

3.2.1 Attributes common to token elements

Several attributes related to text formatting are provided on all presentation token elements except mspace, mchar and mglyph, and on no other elements except mstyle. These are:

Name	values	default
fontsize	number v-unit	inherited
fontweight	normal \| bold	inherited
fontstyle	normal \| italic	normal (except on `<mi>`)
fontfamily	string \| css-fontfamily	inherited
color	#rgb \| #rrggbb \| html-color-name	inherited

(See section 2.3.3 [MathML Attribute Values] for terminology and notation used in attribute value descriptions.)

Token elements (other than mspace) should be rendered as their content (i.e. in the visual case, as a closely-spaced horizontal row of standard glyphs for the characters in their content) using the attributes listed above, with surrounding spacing modified by rules or attributes specific to each type of token element. Some of the individual attributes are further discussed below.

Recall that all MathML elements, including tokens, accept class, style, and id attributes for compatibility with style sheet mechanisms, as described in section 2.3.4 [Attributes Shared by all MathML Elements]. In general, the font properties controlled by the attributes listed above are better handled using CSS or XSL style sheets depending on the context.

MathML expressions are often embedded in a textual data format such as HTML, and their renderings are likewise embedded in a rendering of the surrounding text. The renderer of the surrounding text (e.g. a browser) should provide the MathML renderer with information about the rendering environment, including attributes of the surrounding text such as its font size, so that the MathML can be rendered in a compatible style. For this reason, most attribute values affecting text rendering are inherited from the rendering environment, as shown in the `default' column in the table above. (Note that it is also important for the rendering environment to provide the renderer with additional information, such as the baseline position of surrounding text, which is not specified by any MathML attributes.)

The exception to the general pattern of inheritance is the fontstyle attribute, whose default value is normal (non-slanted) for most tokens, but for mi depends on the content in a way described in the section about mi, section 3.2.2 [Identifier (mi)]. Note that fontstyle is not inherited in MathML, even though the corresponding CSS1 property `font-style' is inherited in CSS.

The fontsize attribute specifies the desired font size. v-unit represents a unit of vertical length (see section 2.3.3.3 [CSS-compatible attributes]). The most common unit for specifying font sizes in typesetting is pt (points).

If the requested size of the current font is not available, the renderer should approximate it in the manner likely to lead to the most intelligible, highest quality rendering.

Many MathML elements automatically change fontsize in some of their children; see the discussion of scriptlevel in the section on mstyle, section 3.3.4 [Style Change (mstyle)].

The value of the fontfamily attribute should be the name of a font that may be available to a MathML renderer, or information that permits the renderer to select a font in some manner; acceptable values and their meanings are dependent on the specific renderer and rendering environment in use, and are not specified by MathML (but see the note about css-fontfamily below). (Note that the renderer's mechanism for finding fonts by name may be case-sensitive.)

If the value of fontfamily is not recognized by a particular MathML renderer, this should never be interpreted as a MathML error; rather, the renderer should either use a font that it considers to be a suitable substitute for the requested font, or ignore the attribute and act as if no value had been given.

Note that any use of the fontfamily attribute is unlikely to be portable across all MathML renderers. In particular, it should never be used to try to achieve the effect of a reference to an extended character (for example, by using a reference to a character in some symbol font that maps ordinary characters to glyphs for extended characters). As a corollary to this principle, MathML renderers should attempt to always produce intelligible renderings for the extended characters listed in chapter 6 [Entities, Characters and Fonts], even when these characters are not available in the font family indicated. Such a rendering is always possible - as a last resort, a character can be rendered to appear as an XML-style entity reference using one of the entity names given for the same character in chapter 6 [Entities, Characters and Fonts].

The symbol css-fontfamily refers to a legal value for the font-family property in CSS1, which is a comma-separated list of alternative font family names or generic font types in order of preference, as documented in more detail in CSS1. MathML renderers are encouraged to make use of the CSS syntax for specifying fonts when this is practical in their rendering environment, even if they do not otherwise support CSS. (See also the subsection CSS-compatible attributes within section 2.3.3.3 [CSS-compatible attributes].

The syntax and meaning of the color attribute are as described for the same attribute of <mstyle> (section 3.3.4 [Style Change (mstyle)]).

3.2.2 Identifier (`mi`)

3.2.2.1 Description

An 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.

Not all `mathematical identifiers' are represented by mi elements - for example, subscripted or primed variables should be represented using msub or msup respectively. Conversely, arbitrary text playing the role of a `term' (such as an ellipsis in a summed series) can be represented using an mi element, as shown in an example in section 3.2.5.4 [Mixing text and mathematics].

It should be stressed that mi is a presentation element, and as such, it only indicates that its content should be rendered as an identifier. In the majority of cases, the contents of an mi will actually represent a mathematical identifier such as a variable or function name. However, as the preceding paragraph indicates, the correspondence between notations that should render like identifiers and notations that are actually intended to represent mathematical identifiers is not perfect. For an element whose semantics is guaranteed to be that of an identifier, see the description of ci in chapter 4 [Content Markup].

3.2.2.2 Attributes

mi elements accept the attributes listed in section 3.2.1 [Attributes common to token elements], but in one case with a different default value:

Name	values	default
fontstyle	normal \| italic	(depends on content; described below)

A typical graphical renderer would render an mi element as the characters in its content, with no extra spacing around the characters (except spacing associated with neighboring elements). The default fontstyle would (typically) be normal (non-slanted) unless the content is a single character, in which case it would be italic. Note that this rule for fontstyle is specific to mi elements; the default value for the fontstyle attribute of other MathML token elements is normal.

3.2.2.3 Examples

<mi> x </mi>
<mi> D </mi>
<mi> sin </mi>
<mi></mi>

An mi element with no content is allowed; <mi></mi> might, for example, be used by an `expression editor' to represent a location in a MathML expression which requires a `term' (according to conventional syntax for mathematics) but does not yet contain one.

Identifiers include function names such as `sin'. Expressions such as `sin x' should be written using the ⁡ operator (which also has the short name ⁡) as shown below; see also the discussion of invisible operators in section 3.2.4 [Operator, Fence, Separator or Accent (mo)].

<mrow>
   <mi> sin </mi>
   <mo> &ApplyFunction; </mo>
   <mi> x </mi>
</mrow>

Miscellaneous text that should be treated as a `term' can also be represented by an mi element, as in:

<mrow>
   <mn> 1 </mn>
   <mo> + </mo>
   <mi> ... </mi>
   <mo> + </mo>
   <mi> n </mi>
</mrow>

When an mi is used in such exceptional situations, explicitly setting the fontstyle attribute may give better results than the default behavior of some renderers.

The names of symbolic constants should be represented as mi elements:

<mi> &pi; </mi>
<mi> &ImaginaryI; </mi>
<mi> &ExponentialE; </mi>

Use of special entity references for such constants can simplify the interpretation of MathML presentation elements. See chapter 6 [Entities, Characters and Fonts] for a complete list of character entity references in MathML.

3.2.3 Number (`mn`)

3.2.3.1 Description

An 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 concept of a mathematical `number' depends on the context, and is not well-defined in the abstract. As a consequence, not all mathematical numbers should be represented using mn; examples of mathematical numbers that should be represented differently are shown below, and include negative numbers, complex numbers, ratios of numbers shown as fractions, and names of numeric constants.

Conversely, since mn is a presentation element, there are a few situations where it may desirable to include arbitrary text in the content of an mn that should merely render as a numeric literal, even though that content may not be unambiguously interpretable as a number according to any particular standard encoding of numbers as character sequences. As a general rule, however, the mn element should be reserved for situations where its content is actually intended to represent a numeric quantity in some fashion. For an element whose semantics are guaranteed to be that of a particular kind of mathematical number, see the description of cn in chapter 4 [Content Markup].

3.2.3.2 Attributes

mn elements accept the attributes listed in section 3.2.1 [Attributes common to token elements].

A typical graphical renderer would render an mn element as the characters of its content, with no extra spacing around them (except spacing from neighboring elements such as mo). Unlike mi, mn elements are (typically) rendered in an unslanted font by default, regardless of their content.

3.2.3.3 Examples

<mn> 2 </mn>
<mn> 0.123 </mn>
<mn> 1,000,000 </mn>
<mn> 2.1e10 </mn>
<mn> 0xFFEF </mn>
<mn> MCMLXIX </mn>
<mn> twenty one </mn>

3.2.3.4 Numbers that should not be written using `mn` alone

Many mathematical numbers should be represented using presentation elements other than mn alone; this includes negative numbers, complex numbers, ratios of numbers shown as fractions, and names of numeric constants. Examples of MathML representations of such numbers include:

<mrow> <mo> - </mo> <mn> 1 </mn> </mrow>
<mrow>
   <mn> 2 </mn>
   <mo> + </mo>
   <mrow>
      <mn> 3 </mn>
      <mo> &InvisibleTimes; </mo>
      <mi> &ImaginaryI; </mi>
   </mrow>
</mrow>
<mfrac> <mn> 1 </mn> <mn> 2 </mn> </mfrac>
<mi> &pi; </mi>
<mi> &ExponentialE; </mi>

3.2.4 Operator, Fence, Separator or Accent (`mo`)

3.2.4.1 Description

An 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.

The term `operator' as used in the present chapter means any symbol or notation that should render as an operator, and that is therefore representable by an mo element. That is, the term `operator' includes any ordinary operator, fence, separator, or accent unless otherwise specified or clear from the context.

All such symbols are represented in MathML with mo elements since they are subject to essentially the same rendering attributes and rules; subtle distinctions in the rendering of these classes of symbols, when they exist, are supported using the boolean attributes fence, separator and accent, which can be used to distinguish these cases.

A key feature of the mo element is that its default attribute values are set on a case-by-case basis from an `operator dictionary' as explained below. In particular, default values for fence, separator and accent can usually be found in the operator dictionary and therefore need not be specified on each mo element.

Note that some mathematical operators are represented not by mo elements alone, but by mo elements `embellished' with (for example) surrounding superscripts; this is further described below. Conversely, as presentation elements, mo elements can contain arbitrary text, even when that text has no standard interpretation as an operator; for an example, see the discussion `Mixing text and mathematics' in section 3.2.5 [Text (mtext)]. See also chapter 4 [Content Markup] for definitions of MathML content elements that are guaranteed to have the semantics of specific mathematical operators.

3.2.4.2 Attributes

mo elements accept the attributes listed in section 3.2.1 [Attributes common to token elements], and the additional attributes listed here. Most attributes get their default values from the section 3.2.4.7.1 [The operator dictionary], as described later in this section. When a dictionary entry is not found for a given mo element, the default value shown here in parentheses is used.

Name	values	default
form	prefix \| infix \| postfix	set by position of operator in an `mrow` (rule given below); used with `mo` content to index operator dictionary
fence	true \| false	set by dictionary (false)
separator	true \| false	set by dictionary (false)
lspace	number h-unit \| namedspace	set by dictionary (thickmathspace)
rspace	number h-unit \| namedspace	set by dictionary (thickmathspace)
stretchy	true \| false	set by dictionary (false)
symmetric	true \| false	set by dictionary (true)
maxsize	number [ v-unit \| h-unit ] \| namedspace \| infinity	set by dictionary (infinity)
minsize	number [ v-unit \| h-unit ] \| namedspace	set by dictionary (1)
largeop	true \| false	set by dictionary (false)
movablelimits	true \| false	set by dictionary (false)
accent	true \| false	set by dictionary (false)

h-unit represents a unit of horizontal length, and v-unit represents a unit of vertical length (see section 2.3.3.2 [Attributes with units]). namedspace is one of veryverythinmathspace, verythinmathspace, thinmathspace, mediummathspace, thickmathspace, verythickmathspace, or veryverythickmathspace. These values are settable by the mstyle element which is discussed in section 3.3.4 [Style Change (mstyle)]. The default values of veryverythinmathspace... veryverythickmathspace are 1/18em...7/18em, respectively.

If no unit is given with maxsize or minsize, the number is a multiplier of the normal size of the operator in the direction (or directions) in which it stretches. These attributes are further explained below.

Typical graphical renderers show all mo elements as the characters of their content, with additional spacing around the element determined from the attributes listed above. Detailed rules for determining operator spacing in visual renderings are described in a subsection below. As always, MathML does not require a specific rendering, and these rules are provided as suggestions for the convenience of implementors.

Renderers without access to complete fonts for the MathML character set may choose not to render an mo element as precisely the characters in its content in some cases. For example, <mo> ≤ </mo> might be rendered as <= to a terminal. However, as a general rule, renderers should attempt to render the content of an mo element as literally as possible. That is, <mo> &le </mo> and <mo> <= </mo> should render differently. (The first one should render as a single extended character representing a less-than-or-equal-to sign, and the second one as the two-character sequence <=.)

3.2.4.3 Examples with ordinary operators

<mo> + </mo>
<mo> &lt; </mo>
<mo> &le; </mo>
<mo> &lt;= </mo>
<mo> ++ </mo>
<mo> &sum; </mo>
<mo> .NOT. </mo>
<mo> and </mo>
<mo> &InvisibleTimes; </mo>

3.2.4.4 Examples with fences and separators

Note that the mo elements in these examples don't need explicit fence or separator attributes, since these can be found using the operator dictionary as described below. Some of these examples could also be encoded using the mfenced element described in section 3.3.8 [Content Inside Pair of Fences (mfenced)].

(a+b)

<mrow>
   <mo> ( </mo>
   <mrow>
      <mi> a </mi>
      <mo> + </mo>
      <mi> b </mi>
   </mrow>
   <mo> ) </mo>
</mrow>

[0,1)

<mrow>
   <mo> [ </mo>
   <mrow>
      <mn> 0 </mn>
      <mo> , </mo>
      <mn> 1 </mn>
   </mrow>
   <mo> ) </mo>
</mrow>

f(x,y)

<mrow>
   <mi> f </mi>
   <mo> &ApplyFunction; </mo>
   <mrow>
      <mo> ( </mo>
      <mrow>
         <mi> x </mi>
         <mo> , </mo>
         <mi> y </mi>
      </mrow>
      <mo> ) </mo>
   </mrow>
</mrow>

3.2.4.5 Invisible operators

Certain operators that are `invisible' in traditional mathematical notation should be represented using specific entity references within mo elements, rather than simply by nothing. The entity references used for these `invisible operators' are:

Full name	Short name	Examples of use
`⁢`	`⁢`	xy
`⁡`	`⁡`	f(x) sin x
`⁣`	`⁣`	m₁₂

The MathML representations of the examples in the above table are:

<mrow>
   <mi> x </mi>
   <mo> &InvisibleTimes; </mo>
   <mi> y </mi>
</mrow>
<mrow>
   <mi> f </mi>
   <mo> &ApplyFunction; </mo>
   <mrow>
      <mo> ( </mo>
      <mi> x </mi>
      <mo> ) </mo>
   </mrow>
</mrow>
<mrow>
   <mi> sin </mi>
   <mo> &ApplyFunction; </mo>
   <mi> x </mi>
</mrow>
<msub>
   <mi> m </mi>
   <mrow>
      <mn> 1 </mn>
      <mo> &InvisibleComma; </mo>
      <mn> 2 </mn>
   </mrow>
</msub>

The reasons for using specific mo elements for invisible operators include:

such operators should often have specific effects on visual rendering (particularly spacing and linebreaking rules) that are not the same as either the lack of any operator, or spacing represented by <mspace/> or mtext elements;
these operators should often have specific audio renderings different than that of the lack of any operator;
automatic semantic interpretation of MathML presentation elements is made easier by the explicit specification of such operators.

For example, an audio renderer might render f(x) (represented as in the above examples) by speaking `f of x', but use the word `times' in its rendering of xy. Although its rendering must still be different depending on the structure of neighboring elements (sometimes leaving out `of' or `times' entirely), its task is made much easier by the use of a different mo element for each invisible operator.

3.2.4.6 Entity references for other special operators

MathML also includes &DifferentialD; for use in an mo element representing the differential operator symbol usually denoted by `d'. The reasons for explicitly using this special entity are similar to those for using the special entities for invisible operators described in the preceding section.

3.2.4.7 Detailed rendering rules for `mo` elements

Typical visual rendering behaviors for mo elements are more complex than for the other MathML token elements, so the rules for rendering them are described in this separate subsection.

Note that, like all rendering rules in MathML, these rules are suggestions rather than requirements. Furthermore, no attempt is made to specify the rendering completely; rather, enough information is given to make the intended effect of the various rendering attributes as clear as possible.

The operator dictionary

Many mathematical symbols, such as an integral sign, a plus sign, or a parenthesis, have a well-established, predictable, traditional notational usage. Typically, this usage amounts to certain default attribute values for mo elements with specific contents and a specific form attribute. Since these defaults vary from symbol to symbol, MathML anticipates that renderers will have an `operator dictionary' of default attributes for mo elements (see appendix D [Operator Dictionary]) indexed by each mo element's content and form attribute. If an mo element is not listed in the dictionary, the default values shown in parentheses in the table of attributes for mo should be used, since these values are typically acceptable for a generic operator.

Some operators are `overloaded', in the sense that they can occur in more than one form (prefix, infix, or postfix), with possibly different rendering properties for each form. For example, `+' can be either a prefix or an infix operator. Typically, a visual renderer would add space around both sides of an infix operator, while only on the left of a prefix operator. The form attribute allows specification of which form to use, in case more than one form is possible according to the operator dictionary and the default value described below is not suitable.

Default value of the `form` attribute

The form attribute does not usually have to be specified explicitly, since there are effective heuristic rules for inferring the value of the form attribute from the context. If it is not specified, and there is more than one possible form in the dictionary for an mo element with given content, the renderer should choose which form to use as follows (but see the exception for embellished operators, described later):

If the operator is the first argument in an mrow of length (i.e. number of arguments) greater than one (ignoring all space-like arguments (see section 3.2.6 [Space (mspace)]) in the determination of both the length and the first argument), the prefix form is used;
if it is the last argument in an mrow of length greater than one (ignoring all space-like arguments), the postfix form is used;
in all other cases, including when the operator is not part of an mrow, the infix form is used.

Note that these rules make reference to the mrow in which the mo element lies. In some situations, this mrow might be an inferred mrow implicitly present around the arguments of an element such as msqrt or mtd.

Opening (left) fences should have form="prefix", and closing (right) fences should have form="postfix"; separators are usually `infix', but not always, depending on their surroundings. As with ordinary operators, these values do not usually need to be specified explicitly.

If the operator does not occur in the dictionary with the specified form, the renderer should use one of the forms that is available there, in the order of preference: infix, postfix, prefix; if no forms are available for the given mo element content, the renderer should use the defaults given in parentheses in the table of attributes for mo.

Exception for embellished operators

There is one exception to the above rules for choosing an mo element's default form attribute. An mo element that is `embellished' by one or more nested subscripts, superscripts, surrounding text or whitespace, or style changes behaves differently. It is the embellished operator as a whole (this is defined precisely, below) whose position in an mrow is examined by the above rules and whose surrounding spacing is affected by its form, not the mo element at its core; however, the attributes influencing this surrounding spacing are taken from the mo element at the core (or from that element's dictionary entry).

For example, the `+₄' in a+₄b should be considered an infix operator as a whole, due to its position in the middle of an mrow, but its rendering attributes should be taken from the mo element representing the `+', or when those are not specified explicitly, from the operator dictionary entry for <mo form="infix"> + </mo>. The precise definition of an `embellished operator' is:

an mo element;
or one of the elements msub, msup, msubsup, munder, mover, munderover, mmultiscripts, mfrac, or semantics (section 4.2.6 [Syntax and Semantics]), whose first argument exists and is an embellished operator;
or one of the elements mstyle, mphantom, or mpadded, such that an mrow containing the same arguments would be an embellished operator;
or an maction element whose selected sub-expression exists and is an embellished operator;
or an mrow whose arguments consist (in any order) of one embellished operator and zero or more space-like elements.

Note that this definition permits nested embellishment only when there are no intervening enclosing elements not in the above list.

The above rules for choosing operator forms and defining embellished operators are chosen so that in all ordinary cases it will not be necessary for the author to specify a form attribute.

Rationale for definition of embellished operators

The following notes are included as a rationale for certain aspects of the above definitions, but should not be important for most users of MathML.

An mfrac is included as an `embellisher' because of the common notation for a differential operator:

<mfrac>
   <mo> &DifferentialD; </mo>
   <mrow>
      <mo> &DifferentialD; </mo>
      <mi> x </mi>
   </mrow>
</mfrac>

Since the definition of embellished operator affects the use of the attributes related to stretching, it is important that it includes embellished fences as well as ordinary operators; thus it applies to any mo element.

Note that an mrow containing a single argument is an embellished operator if and only if its argument is an embellished operator. This is because an mrow with a single argument must be equivalent in all respects to that argument alone (as discussed in section 3.3.1 [Horizontally Group Sub-Expressions (mrow)]). This means that an mo element that is the sole argument of an mrow will determine its default form attribute based on that mrow's position in a surrounding, perhaps inferred, mrow (if there is one), rather than based on its own position in the mrow it is the sole argument of.

Note that the above definition defines every mo element to be `embellished' - that is, `embellished operator' can be considered (and implemented in renderers) as a special class of MathML expressions, of which mo is a specific case.

Spacing around an operator

The amount of space added around an operator (or embellished operator), when it occurs in an mrow, can be directly specified by the lspace and rspace attributes. These values are in ems if no units are given. By convention, operators that tend to bind tightly to their arguments have smaller values for spacing than operators that tend to bind less tightly. This convention should be followed in the operator dictionary included with a MathML renderer. In T_EX, these values can only be one of three values; typically they are 3/18em, 4/18em, and 5/18em. MathML does not impose this limit.

Some renderers may choose to use no space around most operators appearing within subscripts or superscripts, as is done in T_EX.

Non-graphical renderers should treat spacing attributes, and other rendering attributes described here, in analogous ways for their rendering medium.

3.2.4.8 Stretching of operators, fences and accents

Four attributes govern whether and how an operator (perhaps embellished) stretches so that it matches the size of other elements: stretchy, symmetric, maxsize, and minsize. If an operator has the attribute stretchy=true, then it (that is, each character in its content) obeys the stretching rules listed below, given the constraints imposed by the fonts and font rendering system. In practice, typical renderers will only be able to stretch a small set of characters, and quite possibly will only be able to generate a discrete set of character sizes.

There is no provision in MathML for specifying in which direction (horizontal or vertical) to stretch a specific character or operator; rather, when stretchy=true it should be stretched in each direction for which stretching is possible. It is up to the renderer to know in which directions it is able to stretch each character. (Most characters can be stretched in at most one direction by typical renderers, but some renderers may be able to stretch certain characters, such as diagonal arrows, in both directions independently.)

The minsize and maxsize attributes limit the amount of stretching (in either direction). These two attributes are given as multipliers of the operator's normal size in the direction or directions of stretching, or as absolute sizes using units. For example, if a character has maxsize="3", then it can grow to be no more than three times its normal (unstretched) size.

The symmetric attribute governs whether the height and depth above and below the axis of the character are forced to be equal (by forcing both height and depth to become the maximum of the two). An example of a situation where one might set symmetric=false arises with parentheses around a matrix not aligned on the axis, which frequently occurs when multiplying non-square matrices. In this case, one wants the parentheses to stretch to cover the matrix, whereas stretching the parentheses symmetrically would cause them to protrude beyond one edge of the matrix. The symmetric attribute only applies to characters that stretch vertically (otherwise it is ignored).

If a stretchy mo element is embellished (as defined earlier in this section), the mo element at its core is stretched to a size based on the context of the embellished operator as a whole, i.e. to the same size as if the embellishments were not present. For example, the parentheses in the following example (which would typically be set to be stretchy by the operator dictionary) will be stretched to the same size as each other, and the same size they would have if they were not underlined and overlined, and furthermore will cover the same vertical interval:

<mrow>
   <munder>
      <mo> ( </mo>
      <mo> &UnderBar; </mo>
   </munder>
   <mfrac>
      <mi> a </mi>
      <mi> b </mi>
   </mfrac>
   <mover>
      <mo> ) </mo>
      <mo> &OverBar; </mo>
   </mover>
</mrow>

Note that this means that the stretching rules given below must refer to the context of the embellished operator as a whole, not just to the mo element itself.

Example of stretchy attributes

This shows one way to set the maximum size of a parenthesis so that it does not grow, even though its default value is stretchy=true.

<mrow>
   <mo maxsize="1"> ( </mo>
   <mfrac>
      <mi> a </mi> <mi> b </mi>
   </mfrac>
   <mo maxsize="1"> ) </mo>
</mrow>

The above should render as $(\frac{a}{b})$ as opposed to the default rendering $\left(\frac{a}{b}\right)$ .

Note that each parenthesis is sized independently; if only one of them had maxsize="1", they would render with different sizes.

Vertical Stretching Rules

If a stretchy operator is a direct sub-expression of an mrow element, or is the sole direct sub-expression of an mtd element in some row of a table, then it should stretch to cover the height and depth (above and below the axis) of the non-stretchy direct sub-expressions in the mrow element or table row, unless stretching is constrained by minsize or maxsize attributes.
In the case of an embellished stretchy operator, the preceding rule applies to the stretchy operator at its core.
If symmetric=true, then the maximum of the height and depth is used to determine the size, before application of the minsize or maxsize attributes.
The preceding rules also apply in situations where the mrow element is inferred.

Most common opening and closing fences are defined in the operator dictionary to stretch by default; and they stretch vertically. Also, operators such as ∑, ∫, /, and vertical arrows stretch vertically by default.

In the case of a stretchy operator in a table cell (i.e. within an mtd element), the above rules assume each cell of the table row containing the stretchy operator covers exactly one row. (Equivalently, the value of the rowspan attribute is assumed to be 1 for all the table cells in the table row, including the cell containing the operator.) When this is not the case, the operator should only be stretched vertically to cover those table cells that are entirely within the set of table rows that the operator's cell covers. Table cells that extend into rows not covered by the stretchy operator's table cell should be ignored. See section 3.5.4.2 [Attributes] for details about the the rowspan attribute.

Horizontal Stretching Rules

If a stretchy operator, or an embellished stretchy operator, is a direct sub-expression of an munder, mover, or munderover element, or if it is the sole direct sub-expression of an mtd element in some column of a table (see mtable), then it, or the mo element at its core, should stretch to cover the width of the other direct sub-expressions in the given element (or in the same table column), given the constraints mentioned above.
If a stretchy operator is a direct sub-expression of an munder, mover, or munderover element, or if it is the sole direct sub-expression of an mtd element in some column of a table, then it should stretch to cover the width of the other direct sub-expressions in the given element (or in the same table column), given the constraints mentioned above.
In the case of an embellished stretchy operator, the preceding rule applies to the stretchy operator at its core.

By default, most horizontal arrows and some accents stretch horizontally.

In the case of a stretchy operator in a table cell (i.e. within an mtd element), the above rules assume each cell of the table column containing the stretchy operator covers exactly one column. (Equivalently, the value of the columnspan attribute is assumed to be 1 for all the table cells in the table row, including the cell containing the operator.) When this is not the case, the operator should only be stretched horizontally to cover those table cells that are entirely within the set of table columns that the operator's cell covers. Table cells that extend into columns not covered by the stretchy operator's table cell should be ignored. See section 3.5.4.2 [Attributes] for details about the the rowspan attribute.

The rules for horizontal stretching include mtd elements to allow arrows to stretch for use in commutative diagrams laid out using mtable. The rules for the horizontal stretchiness include scripts to make examples such as the following work:

<mrow>
   <mi> x </mi>
   <munder>
      <mo> &RightArrow; </mo>
      <mtext> maps to </mtext>
   </munder>
   <mi> y </mi>
</mrow>

This displays as $x \widearrow{\mathrm{maps~to}} y$ .

Rules Common to both Vertical and Horizontal Stretching

If a stretchy operator is not required to stretch (i.e. if it is not in one of the locations mentioned above, or if there are no other expressions whose size it should stretch to match), then it has the standard (unstretched) size determined by the font and current fontsize.

If a stretchy operator is required to stretch, but all other expressions in the containing element or object (as described above) are also stretchy, all elements that can stretch should grow to the maximum of the normal unstretched sizes of all elements in the containing object, if they can grow that large. If the value of minsize or maxsize prevents this then that (min or max) size is used.

For example, in an mrow containing nothing but vertically stretchy operators, each of the operators should stretch to the maximum of all of their normal unstretched sizes, provided no other attributes are set that override this behavior. Of course, limitations in fonts or font rendering may result in the final, stretched sizes being only approximately the same.

3.2.4.9 Other attributes of `mo`

The largeop attribute specifies whether the operator should be drawn larger than normal if displaystyle=true in the current rendering environment. This roughly corresponds to T_EX's \displaystyle style setting. MathML uses two attributes, displaystyle and scriptlevel, to control orthogonal presentation features that T_EX encodes into one `style' attribute with values \displaystyle, \textstyle, \scriptstyle, and \scriptscriptstyle. These attributes are discussed further in section 3.3.4 [Style Change (mstyle)] describing the mstyle element. Note that these attributes can be specified directly on an mstyle element's begin tag, but not on most other elements. Examples of large operators include ∫ and ∏.

The movablelimits attribute specifies whether underscripts and overscripts attached to this mo element should be drawn as subscripts and superscripts when displaystyle=false. movablelimits=false means that underscripts and overscripts should never be drawn as subscripts and superscripts. In general, displaystyle is true for displayed mathematics and false for inline mathematics. Also, displaystyle is false by default within tables, scripts and fractions, and a few other exceptional situations detailed in section 3.3.4 [Style Change (mstyle)]. Thus, operators with movablelimits=true will display with limits (i.e. underscripts and overscripts) in displayed mathematics, and with subscripts and superscripts in inline mathematics, tables, scripts and so on. Examples of operators that typically have movablelimits=true are sum, prod, and lim.

The accent attribute determines whether this operator should be treated by default as an accent (diacritical mark) when used as an underscript or overscript; see munder, mover, and munderover (section 3.4.4 [Underscript (munder)], section 3.4.5 [Overscript (mover)] and section 3.4.6 [Underscript-overscript Pair (munderover)]).

The separator attribute may affect automatic linebreaking in renderers that position ordinary infix operators at the beginnings of broken lines rather than at the ends (that is, which avoid linebreaking just after such operators), since linebreaking should be avoided just before separators, but is acceptable just after them.

The fence attribute has no effect in the suggested visual rendering rules given here; it is not needed for properly rendering traditional notation using these rules. It is provided so that specific MathML renderers, especially non-visual renderers, have the option of using this information.

3.2.5 Text (`mtext`)

3.2.5.1 Description

An 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 that is not central to the mathematical meaning or notational structure of the expression it is contained in.

Note that some text with a clearly defined notational role might be more appropriately marked up using mi or mo; this is discussed further below.

An mtext element can be used to contain `renderable whitespace', i.e. invisible characters that are intended to alter the positioning of surrounding elements. In non-graphical media, such characters are intended to have an analogous effect, such as introducing positive or negative time delays or affecting rhythm in an audio renderer. This is not related to any whitespace in the source MathML consisting of blanks, newlines, tabs, or carriage returns; whitespace present directly in the source is trimmed and collapsed, as described in section 2.3.5 [Collapsing Whitespace in Input]. Whitespace that is intended to be rendered as part of an element's content must be represented by entity references (unless it consists only of single blanks between non-whitespace characters).

Renderable whitespace can have a positive or negative width, as in   and &NegativeThinSpace;, or zero width, as in &ZeroWidthSpace;. The complete list of such characters is given in chapter 6 [Entities, Characters and Fonts]. Note that there is no formal distinction in MathML between renderable whitespace characters and any other class of characters, in mtext or in any other element.

Renderable whitespace can also include characters that affect alignment or linebreaking. Some of these characters are:

Entity name	Purpose (rough description)
NewLine	start a new line and do not indent
IndentingNewLine	start a new line and do indent
NoBreak	do not allow a linebreak here
GoodBreak	if a linebreak is needed on the line, here is a good spot
BadBreak	if a linebreak is needed on the line, try to avoid breaking here

For the complete list of MathML entities, consult chapter 6 [Entities, Characters and Fonts].

3.2.5.2 Attributes

mtext elements accept the attributes listed in section 3.2.1 [Attributes common to token elements].

See also the warnings about the legal grouping of `space-like elements' in section 3.2.6 [Space (mspace)], and about the use of such elements for `tweaking' or conveying meaning in section 3.3.6 [Adjust Space Around Content (mpadded)].

3.2.5.3 Examples

<mtext> Theorem 1: </mtext>
<mtext> &ThinSpace; </mtext>
<mtext> &ThickSpace;&ThickSpace; </mtext>
<mtext> /* a comment */ </mtext>

3.2.5.4 Mixing text and mathematics

In some cases, text embedded in mathematics could be more appropriately represented using mo or mi elements. For example, the expression `there exists $\delta>0$ such that f(x) <1' is equivalent to $\exists \delta>0 \backepsilon f(x)<1$ and could be represented as:

<mrow>
   <mo> there exists </mo>
   <mrow>
      <mrow>
         <mi> &delta; </mi>
         <mo> &gt; </mo>
         <mn> 0 </mn>
      </mrow>
      <mo> such that </mo>
      <mrow>
         <mrow>
            <mi> f </mi>
            <mo> &ApplyFunction; </mo>
            <mrow>
               <mo> ( </mo>
               <mi> x </mi>
               <mo> ) </mo>
            </mrow>
         </mrow>
         <mo> &lt; </mo>
         <mn> 1 </mn>
      </mrow>
   </mrow>
</mrow>

An example involving an mi element is: x+x²+···+xⁿ. In this example, ellipsis should be represented using an mi element, since it takes the place of a term in the sum (see section 3.2.2 [Identifier (mi)], mi).

On the other hand, expository text within MathML is best represented with an mtext element. An example of this is:

Theorem 1: if x > 1, then x² > x.

However, when MathML is embedded in HTML, the example is probably best rendered with only the two inequalities represented as MathML at all, letting the text be part of the surrounding HTML.

Another factor to consider in deciding how to mark up text is the effect on rendering. Text enclosed in an mo element is unlikely to be found in a renderer's operator dictionary, so it will be rendered with the format and spacing appropriate for an `unrecognized operator', which may or may not be better than the format and spacing for `text' obtained by using an mtext element. An ellipsis entity in an mi element is apt to be spaced more appropriately for taking the place of a term within a series than if it appeared in an mtext element.

3.2.6 Space (`mspace`)

3.2.6.1 Description

An mspace empty element represents a blank space of any desired size, as set by its attributes. The default value for each attribute is 0em or 0ex, so it will not be useful without some attributes specified.

3.2.6.2 Attributes

Name	values	default
width	number h-unit \| namedspace	0em
height	number v-unit	0ex
depth	number v-unit	0ex

h-unit and v-unit represent units of horizontal or vertical length, respectively (see section 2.3.3.2 [Attributes with units]).

Note the warning about the legal grouping of `space-like elements' given below, and the warning about the use of such elements for `tweaking' or conveying meaning in section 3.3.6 [Adjust Space Around Content (mpadded)]. See also the other elements that can render as whitespace, namely mtext, mphantom, and maligngroup.

3.2.6.3 Definition of space-like elements

A number of MathML presentation elements are `space-like' 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. For example, space-like elements are handled specially in the suggested rendering rules for mo given in section 3.2.4 [Operator, Fence, Separator or Accent (mo)]. The following MathML elements are defined to be `space-like':

an mtext, mspace, maligngroup, or malignmark element;
an mstyle, mphantom, or mpadded element, all of whose direct sub-expressions are space-like;
an maction element whose selected sub-expression exists and is space-like;
an mrow all of whose direct sub-expressions are space-like.

Note that an mphantom is not automatically defined to be space-like, unless its content is space-like. This is because operator spacing is affected by whether adjacent elements are space-like. 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.

3.2.6.4 Legal grouping of space-like elements

Authors who insert space-like elements or mphantom elements into an existing MathML expression should note that such elements are counted as arguments, in elements that require a specific number of arguments, or that interpret different argument positions differently.

Therefore, space-like elements inserted into such a MathML element should be grouped with a neighboring argument of that element by introducing an mrow for that purpose. For example, to allow for vertical alignment on the right edge of the base of a superscript, the expression

<msup> <mi> x </mi> <malignmark edge="right"/> <mn> 2 </mn> </msup>

is illegal, because msup must have exactly 2 arguments; the correct expression would be:

<msup>
   <mrow>
      <mi> x </mi>
      <malignmark edge="right"/>
   </mrow>
   <mn> 2 </mn>
</msup>

See also the warning about `tweaking' in section 3.3.6 [Adjust Space Around Content (mpadded)].

3.2.7 String Literal (`ms`)

3.2.7.1 Description

The ms element is used to represent `string literals' in expressions meant to be interpreted by computer algebra systems or other systems containing `programming languages'. By default, string literals are displayed surrounded by double quotes. As explained in section 3.2.5 [Text (mtext)], ordinary text embedded in a mathematical expression should be marked up with mtext, or in some cases mo or mi, but never with ms.

Note that the string literals encoded by ms are `Unicode strings' rather than `ASCII strings'. In practice, non-ASCII characters will typically be represented by entity references. For example, <ms>&</ms> represents a string literal containing a single character, &, and <ms>&amp;</ms> represents a string literal containing 5 characters, the first one of which is &. (In fact, MathML string literals are even more general than Unicode string literals, since not all MathML entity references necessarily refer to existing Unicode characters, as discussed in chapter 6 [Entities, Characters and Fonts].)

Like all token elements, ms does trim and collapse whitespace in its content according to the rules of section 2.3.5 [Collapsing Whitespace in Input], so whitespace intended to remain in the content should be encoded as described in that section.

3.2.7.2 Attributes

ms elements accept the attributes listed in section 3.2.1 [Attributes common to token elements], and additionally:

Name	values	default
lquote	string	`"`
rquote	string	`"`

In visual renderers, the content of an ms element is typically rendered with no extra spacing added around the string, and a quote character at the beginning and the end of the string. By default, the left and right quote characters are both the standard double quote character ". However, these characters can be changed with the lquote and rquote attributes respectively.

The content of ms elements should be rendered with visible `escaping' of certain characters in the content, including at least `double quote' itself, and preferably whitespace other than individual blanks. The intent is for the viewer to see that the expression is a string literal, and to see exactly which characters form its content. For example, <ms>double quote is "</ms> might be rendered as `double quote is \"'.

3.2.8 Refering to non-ASCII characters (`mchar`)

3.2.8.1 Description

The mchar element is used to reference characters. This provides an alternative to using entity references. Character entities are deprecated for MathML 2.0 because they are not a part of the current proposal for schemas, and documents containing entities are not well-formed MathML in the absence of the MathML DTD.

Numeric character references (e.g. Ӓ ) are not deprecated because they do not have the problems listed above.

mchar is valid content in any MathML token element listed in section 3.1.5 [Summary of Presentation Elements] (mi, etc.) or section 4.2.2 [Containers] (ci, etc.) unless otherwise restricted by an attribute (e.g. base=2 to <cn>).

3.2.8.2 Attributes of `mchar`

Name	values	default
name	string	required

The name attribute must be one of the names specified in chapter 6 [Entities, Characters and Fonts]. It is an error to use a name that is not in that list.

Issue (specific-xref):
The cross-reference above should be made more specific.

3.2.8.3 Examples

In MathML 1.x expressions involving entity references such as <mi> α1 </mi> were common. In MathML 2.0, the equivalent construction using mchar is preferred:

<mi> <mchar name='alpha'/>1 </mi>

3.2.9 Adding new character glyphs to MathML (`mglyph`)

3.2.9.1 Description

Unicode defines a large number of characters used in mathematics, and in most all cases, glyphs representing these characters are widely available in a variety of fonts. Although these characters should meet almost all users needs, MathML recognizes that Mathematics is not static and that new characters are added when convenient. Characters that become well accepted will likely be eventually incorporated by the Unicode Consortium or other standards bodies, but that is often a lengthy process. In the mean time, a mechanism is necessary for accessing glyphs from non-standard fonts representing these characters.

The mglyph element is the means by which users can directly access glyphs for characters that are not defined by Unicode. Similarly, the mglyph element can also be used to select glyph variants for existing Unicode characters, as might be desirable when a glyph variant has begun to differentiate itself as a new character by taking on a distinguished mathematical meaning.

The mglyph element names a specific character glyph, and is valid inside any MathML leaf content listed in section 3.1.5 [Summary of Presentation Elements] (mi, etc.) or section 4.2.2 [Containers] (ci, etc.) unless otherwise restricted by an attribute (e.g. base=2 to <cn>). In order for a visually-oriented renderer to render the character, the renderer must be told what font to use and what index within that font to use.

3.2.9.2 Attributes

Name	values	default
alt	string	required
fontfamily	string \| css-fontfamily	required
index	integer	required

The alt attribute provides an alternate name for the glyph. If the specified font can't be found, the renderer may use this name in a warning message or some unknown glyph notation. The name might also be used by an audio renderer or symbol processing system and should be chosen to be descriptive. The fontfamily and index uniquely identify the mglyph; two mglyphs with the same values for fontfamily and index should be considered identical by applications that must determine whether two characters/glyphs are identical. The alt attribute should not be part of the identity test.

The fontfamily and index attributes name a font and position within that font. All font properties apart from fontfamily are inherited. Variants of the font (e.g., bold) that may be inherited may be ignored if the variant of the font is not present.

Authors should be aware that rendering requires the fonts referenced by mglyph, which the MathML renderer may not have access to or may be not be supported by the system on which the renderer runs. For these reasons, authors are encouraged to use mglyph only when absolutely necessary, and not for stylistic purposes.

3.2.9.3 Example

The following example illustrates how a researcher might use the mglyph construct with an experimental font to work with braid group notation.

<mrow>
  <mi><mglyph fontfamily="my-braid-font" index="2" alt="23braid"></mi>
  <mo>+</mo>
  <mi><mglyph fontfamily="my-braid-font" index="5" alt="132braid"></mi>
  <mo>=</mo>
  <mi><mglyph fontfamily="my-braid-font" index="3" alt="13braid"></mi>

This might render as:

$\includegraphics{braids}$

3.3 General Layout Schemata

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.

3.3.1 Horizontally Group Sub-Expressions (`mrow`)

3.3.1.1 Description

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

Several elements automatically treat their arguments as if they were contained in an mrow element. See the discussion of inferred mrows in section 3.1.3 [Required Arguments]. See also mfenced (section 3.3.8 [Content Inside Pair of Fences (mfenced)]), which can effectively form an mrow containing its arguments separated by commas.

3.3.1.2 Attributes

None (except the attributes allowed for all MathML elements, listed in section 2.3.4 [Attributes Shared by all MathML Elements]).

mrow elements are typically rendered visually as a horizontal row of their arguments, left to right in the order in which the arguments occur, or audibly as a sequence of renderings of the arguments. The description in section 3.2.4 [Operator, Fence, Separator or Accent (mo)] of suggested rendering rules for mo elements assumes that all horizontal spacing between operators and their operands is added by the rendering of mo elements (or, more generally, embellished operators), not by the rendering of the mrows they are contained in.

MathML is designed to allow renderers to automatically linebreak expressions (that is, to break excessively long expressions into several lines), without requiring authors to specify explicitly how this should be done. This is because linebreaking positions can't be chosen well without knowing the width of the display device and the current font size, which for many uses of MathML will not be known except by the renderer at the time of each rendering.

Determining good positions for linebreaks is complex, and rules for this are not described here; whether and how it is done is up to each MathML renderer. Typically, linebreaking will involve selection of `good' points for insertion of linebreaks between successive arguments of mrow elements.

Although MathML does not require linebreaking or specify a particular linebreaking algorithm, it has several features designed to allow such algorithms to produce good results. These include the use of special entities for certain operators, including invisible operators (see section 3.2.4 [Operator, Fence, Separator or Accent (mo)]), or for providing hints related to linebreaking when necessary (see section 3.2.5 [Text (mtext)]), and the ability to use nested mrows to describe sub-expression structure (see below).

`mrow` of one argument

MathML renderers are required to treat an mrow element containing exactly one argument as equivalent in all ways to the single argument occurring alone, provided there are no attributes on the mrow element's begin tag. If there are attributes on the mrow element's begin tag, no requirement of equivalence is imposed. This equivalence condition is intended to simplify the implementation of MathML-generating software such as template-based authoring tools. It directly affects the definitions of embellished operator and space-like element and the rules for determining the default value of the form attribute of an mo element; see sections section 3.2.4 [Operator, Fence, Separator or Accent (mo)] and section 3.2.6 [Space (mspace)]. See also the discussion of equivalence of MathML expressions in chapter 7 [The MathML Interface].

3.3.1.3 Proper grouping of sub-expressions using `mrow`

Sub-Expressions should be grouped by the document author in the same way as they are grouped in the mathematical interpretation of the expression; that is, according to the underlying `syntax tree' of the expression. Specifically, operators and their mathematical arguments should occur in a single mrow; more than one operator should occur directly in one mrow only when they can be considered (in a syntactic sense) to act together on the interleaved arguments, e.g. for a single parenthesized term and its parentheses, for chains of relational operators, or for sequences of terms separated by + and -. A precise rule is given below.

Proper grouping has several purposes: it improves display by possibly affecting spacing; it allows for more intelligent linebreaking and indentation; and it simplifies possible semantic interpretation of presentation elements by computer algebra systems, and audio renderers.

Although improper grouping will sometimes result in suboptimal renderings, and will often make interpretation other than pure visual rendering difficult or impossible, any grouping of expressions using mrow is allowed in MathML syntax; that is, renderers should not assume the rules for proper grouping will be followed.

Precise rule for proper grouping

A precise rule for when and how to nest sub-expressions using mrow is especially desirable when generating MathML automatically by conversion from other formats for displayed mathematics, such as T_EX, which don't always specify how sub-expressions nest. When a precise rule for grouping is desired, the following rule should be used:

Two adjacent operators (i.e. mo elements, possibly embellished), possibly separated by operands (i.e. anything other than operators), should occur in the same mrow only when the left operator has an infix or prefix form (perhaps inferred), the right operator has an infix or postfix form, and the operators are listed in the same group of entries in the operator dictionary provided in appendix D [Operator Dictionary]. In all other cases, nested mrows should be used.

When forming a nested mrow (during generation of MathML) that includes just one of two successive operators with the forms mentioned above (which mean that either operator could in principle act on the intervening operand or operands), it is necessary to decide which operator acts on those operands directly (or would do so, if they were present). Ideally, this should be determined from the original expression; for example, in conversion from an operator-precedence-based format, it would be the operator with the higher precedence. If this cannot be determined directly from the original expression, the operator that occurs later in the suggested operator dictionary (appendix D [Operator Dictionary]) can be assumed to have a higher precedence for this purpose.

Note that the above rule has no effect on whether any MathML expression is valid, only on the recommended way of generating MathML from other formats for displayed mathematics or directly from written notation.

(Some of the terminology used in stating the above rule in defined in section 3.2.4 [Operator, Fence, Separator or Accent (mo)].)

3.3.1.4 Examples

As an example, 2x+y+x should be written as:

<mrow>
  <mrow>
     <mn> 2 </mn>
     <mo> &InvisibleTimes; </mo>
     <mi> x </mi>
  </mrow>
  <mo> + </mo>
  <mi> y </mi>
  <mo> - </mo>
  <mi> z </mi>
</mrow>

The proper encoding of (x, y) furnishes a less obvious example of nesting mrows:

<mrow>
   <mo> ( </mo>
   <mrow>
      <mi> x </mi>
      <mo> , </mo>
      <mi> y </mi>
   </mrow>
   <mo> ) </mo>
</mrow>

In this case, a nested mrow is required inside the parentheses, since parentheses and commas, thought of as fence and separator `operators', do not act together on their arguments.

3.3.2 Fractions (`mfrac`)

3.3.2.1 Description

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

<mfrac> numerator denominator </mfrac>

3.3.2.2 Attributes of `mfrac`

Name	values	default
linethickness	number [ v-unit ] \| thin \| medium \| thick	1 (rule thickness)
numalign	left \| center \| right	center
denomalign	left \| center \| right	center
beveled	true \| false	false

The linethickness attribute indicates the thickness of the horizontal `fraction bar', or `rule', typically used to render fractions. A fraction with linethickness="0" renders without the bar, and might be used within binomial coefficients. A linethickness greater than one might be used with nested fractions. These cases are shown below:

${a \choose b} \quad {a \over b} \above1pt {c \over d}$

In general, the value of linethickness can be a number, as a multiplier of the default thickness of the fraction bar (the default thickness is not specified by MathML), or a number with a unit of vertical length (see section 2.3.3.2 [Attributes with units]), or one of the keywords medium (same as 1), thin (thinner than 1, otherwise up to the renderer), or thick (thicker than 1, otherwise up to the renderer).

The numalign and denomalign attributes control the horizontal alignment of the numerator and denominator respectively. Typically, numerators and denominators are centered, but a very long numerator or denominator might be displayed on several lines and a left alignment might be more appropriate for displaying them.

The beveled attribute determines whether the fraction is displayed with the numerator above the denominator separated by a horizontal line or whether a diagonal line is used to separate a slightly raised numerator from a slightly lowered denominator. The later form corresponds to the attribute value being true and provides for a more compact form for simple numerator and denominators. An example illustrating the beveled form is show below:

$\frac{1}{x^3 + \frac{x}{3}} = \raisebox{1ex}{$1$} \left/ \raisebox{-1ex}{$x^3+\frac{x}{3}$} \right .$

The mfrac element sets displaystyle to false, or if it was already false increments scriptlevel by 1, within numerator and denominator. These attributes are inherited by every element from its rendering environment, but can be set explicitly only on the mstyle element. (See section 3.3.4 [Style Change (mstyle)].)

3.3.2.3 Examples

The examples shown above can be represented in MathML as:

<mrow>
   <mo> ( </mo>
   <mfrac linethickness="0">
      <mi> a </mi>
      <mi> b </mi>
   </mfrac>
   <mo> ) </mo>
</mrow>
<mfrac linethickness="2">
   <mfrac>
      <mi> a </mi>
      <mi> b </mi>
   </mfrac>
   <mfrac>
      <mi> c </mi>
      <mi> d </mi>
   </mfrac>
</mfrac>

<mfrac>
   <mn> 1 </mn>
   <mrow>
      <msup>
         <mi> x </mi>
         <mn> 3 </mn>
       </msup>
       <mo> + </mo>
       <mfrac>
         <mi> x </mi>
         <mn> 3 </mn>
       </mfrac>
   </mrow>
</mfrac>
<mo> = </mo>
<mfrac beveled="true">
   <mn> 1 </mn>
   <mrow>
      <msup>
         <mi> x </mi>
         <mn> 3 </mn>
       </msup>
       <mo> + </mo>
       <mfrac>
         <mi> x </mi>
         <mn> 3 </mn>
       </mfrac>
   </mrow>
</mfrac>

A more generic example is:

<mfrac>
   <mrow>
      <mn> 1 </mn>
      <mo> + </mo>
      <msqrt>
         <mn> 5 </mn>
      </msqrt>
   </mrow>
   <mn> 2 </mn>
</mfrac>

3.3.3 Radicals (`msqrt`, `mroot`)

3.3.3.1 Description

These 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 syntax for these elements is:

<msqrt> base </msqrt>
<mroot> base index </mroot>

The mroot element requires exactly 2 arguments. However, msqrt accepts any number of arguments; if this number is not 1, its contents are treated as a single `inferred mrow' containing its arguments, as described in section 3.1.3 [Required Arguments].

3.3.3.2 Attributes

None (except the attributes allowed for all MathML elements, listed in section 2.3.4 [Attributes Shared by all MathML Elements]).

The mroot element increments scriptlevel by 2, and sets displaystyle to false, within index, but leaves both attributes unchanged within base. The msqrt element leaves both attributes unchanged within all its arguments. These attributes are inherited by every element from its rendering environment, but can be set explicitly only on mstyle. (See section 3.3.4 [Style Change (mstyle)].)

3.3.4 Style Change (`mstyle`)

3.3.4.1 Description

The mstyle element is used to make style changes that affect the rendering of its contents. mstyle can be given any attribute accepted by any MathML presentation element provided that the attribute value is inherited, computed or has a default value; presentation element attributes whose values are required are not accepted by the mstyle element. In addition mstyle can also be given certain special attributes listed below.

The mstyle element accepts any number of arguments. If this number is not 1, its contents are treated as a single `inferred mrow' formed from all its arguments, as described in section 3.1.3 [Required Arguments].

Loosely speaking, the effect of the mstyle element is to change the default value of an attribute for the elements it contains. Style changes work in one of several ways, depending on the way in which default values are specified for an attribute. The cases are:

Some attributes, such as displaystyle or scriptlevel (explained below), are inherited from the surrounding context when they are not explicitly set. Specifying such an attribute on an mstyle element sets the value that will be inherited by its child elements. Unless a child element overrides this inherited value, it will pass it on to its children, and they will pass it to their children, and so on. But if a child element does override it, either by an explicit attribute setting or automatically (as is common for scriptlevel), the new (overriding) value will be passed on to that element's children, and then to their children, etc, until it is again overridden.
Other attributes, such as linethickness on mfrac, have default values that are not normally inherited. That is, if the linethickness attribute is not set on the begin tag of an mfrac element, it will normally use the default value of 1, even if it was contained in a larger mfrac element that set this attribute to a different value. For attributes like this, specifying a value with an mstyle element has the effect of changing the default value for all elements within its scope. The net effect is that setting the attribute value with mstyle propagates the change to all the elements it contains directly or indirectly, except for the individual elements on which the value is overridden. Unlike in the case of inherited attributes, elements that explicitly override this attribute have no effect on this attribute's value in their children.
Another group of attributes, such as stretchy and form, are computed from operator dictionary information, position in the enclosing mrow, and other similar data. For these attributes, a value specified by an enclosing mstyle overrides the value that would normally be computed.

Note that attribute values inherited from an mstyle in any manner affect a given element in the mstyle's content only if that attribute is not given a value in that element's begin tag. On any element for which the attribute is set explicitly, the value specified on the begin tag overrides the inherited value. The only exception to this rule is when the value given on the begin tag is documented as specifying an incremental change to the value inherited from that element's context or rendering environment.

Note also that the difference between inherited and non-inherited attributes set by mstyle, explained above, only matters when the attribute is set on some element within the mstyle's contents that has children also setting it. Thus it never matters for attributes, such as color, which can only be set on token elements (or on mstyle itself).

There is one exceptional element, mpadded, whose attributes cannot be set with mstyle. When the attributes width, height and depth are specified on an mstyle element, they apply only to the mspace element. Similarly, when lspace is set with mstyle, it applies only to the mo element.

3.3.4.2 Attributes

As stated above, mstyle accepts all attributes of all MathML presentation elements which do not have required values. That is, all attributes which have an explicit default value or a default value which is inherited or computed are accepted by the mstyle element. Additionally, mstyle can be given the following special attributes that are implicitly inherited by every MathML element as part of its rendering environment:

Name	values	default
scriptlevel	['+' \| '-'] unsigned-integer	inherited
displaystyle	true \| false	inherited
scriptsizemultiplier	number	0.71
scriptminsize	number v-unit	8pt
color	#rgb \| #rrggbb \| html-color-name	inherited
background	#rgb \| #rrggbb \| transparent \| html-color-name	transparent
veryverythinmathspace	number h-unit	0.0555556em
verythinmathspace	number h-unit	0.111111em
thinmathspace	number h-unit	0.166667em
mediummathspace	number h-unit	0.222222em
thickmathspace	number h-unit	0.277778em
verythickmathspace	number h-unit	0.333333em
veryverythickmathspace	number h-unit	0.388889em

`scriptlevel` and `displaystyle`

MathML uses two attributes, displaystyle and scriptlevel, to control orthogonal presentation features that T_EX encodes into one style attribute with values \displaystyle, \textstyle, \scriptstyle, and \scriptscriptstyle. The corresponding values of displaystyle and scriptlevel for those T_EX styles would be true and 0, false and 0, false and 1, and false and 2, respectively.

The main effect of the displaystyle attribute is that it determines the effect of other attributes such as the largeop and movablescripts attributes of mo. The main effect of the scriptlevel attribute is to control the font size. Typically, the higher the scriptlevel, the smaller the font size. (Non-visual renderers can respond to the font size in an analogous way for their medium.) More sophisticated renderers may also choose to use these attributes in other ways, such as rendering expressions with displaystyle=false in a more vertically compressed manner.

These attributes are given initial values for the outermost expression of an instance of MathML based on its rendering environment. A short list of layout schemata described below modify these values for some of their sub-expressions. Otherwise, values are determined by inheritance whenever they are not directly specified on a given element's start tag.

For an instance of MathML embedded in a textual data format (such as HTML) in `display' mode, i.e. in place of a paragraph, displaystyle = true and scriptlevel = 0 for the outermost expression of the embedded MathML; if the MathML is embedded in `inline' mode, i.e. in place of a character, displaystyle = false and scriptlevel = 0 for the outermost expression. See chapter 7 [The MathML Interface] for further discussion of the distinction between `display' and `inline' embedding of MathML and how this can be specified in particular instances. In general, a MathML renderer may determine these initial values in whatever manner is appropriate for the location and context of the specific instance of MathML it is rendering, or if it has no way to determine this, based on the way it is most likely to be used; as a last resort it is suggested that it use the most generic values displaystyle = "true" and scriptlevel = "0".

The MathML layout schemata that typically display some of their arguments in smaller type or with less vertical spacing, namely the elements for scripts, fractions, radicals, and tables or matrices, set displaystyle to false, and in some cases increase scriptlevel, for those arguments. The new values are inherited by all sub-expressions within those arguments, unless they are overridden.

The specific rules by which each element modifies displaystyle and/or scriptlevel are given in the specification for each element that does so; the complete list of elements that modify either attribute are: the `scripting' elements msub, msup, msubsup, munder, mover, munderover, and mmultiscripts; and the elements mfrac, mroot, and mtable.

When mstyle is given a scriptlevel attribute with no sign, it sets the value of scriptlevel within its contents to the value given, which must be a nonnegative integer. When the attribute value consists of a sign followed by an integer, the value of scriptlevel is incremented (for '+') or decremented (for '-') by the amount given. The incremental syntax for this attribute is an exception to the general rules for setting inherited attributes using mstyle, and is not allowed by any other attribute on mstyle.

Whenever the scriptlevel is changed, either automatically or by being explicitly incremented, decremented, or set, the current font size is multiplied by the value of scriptsizemultiplier to the power of the change in scriptlevel. For example, if scriptlevel is increased by 2, the font size is multiplied by scriptsizemultiplier twice in succession; if scriptlevel is explicitly set to 2 when it had been 3, the font size is divided by scriptsizemultiplier.

The default value of scriptsizemultiplier is less than one (in fact, it is approximately the square root of 1/2), resulting in a smaller font size with increasing scriptlevel. To prevent scripts from becoming unreadably small, the font size is never allowed to go below the value of scriptminsize as a result of a change to scriptlevel, though it can be set to a lower value using the fontsize attribute (section 3.2.1 [Attributes common to token elements]) on mstyle or on token elements. If a change to scriptlevel would cause the font size to become lower than scriptminsize using the above formula, the font size is instead set equal to scriptminsize wi