home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
XML Bible (2nd Edition)
/
XML_Bible_Second_Edition_Hungry_Minds_2001.iso
/
mac
/
specs
/
XML-MathML-20010221
/
xml
/
presentation-markup.xml
< prev
next >
Wrap
Text File
|
2001-02-15
|
276KB
|
6,868 lines
<div1 id="presm" role="chapter3"><head>Presentation Markup</head>
<!-- $Id: presentation-markup.xml,v 1.79 2001/02/15 19:36:14 rminer Exp $ -->
<!--
Principal Authors
Neil Soiffer: overall design; organization and original text of documentation.
Bruce Smith: most precise details of design and documentation;
much additional text of documentation.
Contributors
Robert Miner: original <mfenced> and <maction> designs.
Paul Topping: original alignment element design.
Various members of the W3C Math WG: various design details.
Editors
Patrick Ion & Robert Miner.
-->
<div2 id="presm_intro"><head>Introduction</head>
<p>This chapter specifies the <quote>presentation</quote> elements of
MathML, which can be used to describe the layout structure of mathematical
notation.</p>
<div3><head>What Presentation Elements Represent</head>
<p>Presentation elements correspond to the <quote>constructors</quote>
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).</p>
<p>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.</p>
<p>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 <quote><mi>x</mi> + <mi>a</mi> /
<mi>b</mi></quote>, will often be represented not just by one
<kw role="element">mrow</kw> element (which renders as a horizontal row
of its arguments), but by multiple nested <kw role="element">mrow</kw>
elements corresponding to the nested sub-expressions of which one
mathematical expression is composed – in this case,
<eg role="mathml"><![CDATA[
<mrow>
<mi> x </mi>
<mo> + </mo>
<mrow>
<mi> a </mi>
<mo> / </mo>
<mi> b </mi>
</mrow>
</mrow>
]]></eg>
</p>
<p>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.</p>
<p>Certain MathML characters are used
to name operators or identifiers that in traditional notation render the
same as other symbols, such as <kw role="entity">DifferentialD</kw>, <kw
role="entity">ExponentialE</kw>, or <kw role="entity">ImaginaryI</kw>, or
operators that usually render invisibly, such as <kw
role="entity">InvisibleTimes</kw>, <kw role="entity">ApplyFunction</kw>, or
<kw role="entity">InvisibleComma</kw>. 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
<quote><mi>f</mi>(<mi>x</mi>)</quote> would usually be spoken in English as
<quote><mi>f</mi> of <mi>x</mi></quote> rather than just
<quote><mi>f</mi> <mi>x</mi></quote>; this is expressible in MathML by
the use of the <kw role="entity">ApplyFunction</kw> operator after the
<quote><mi>f</mi></quote>, which (in this case) can be aurally rendered as
<quote>of</quote>.</p>
<p>The complete list of MathML entities is described in <specref ref="chars"/>.</p>
</div3>
<div3><head>Terminology Used In This Chapter</head>
<p>It is strongly recommended that, before reading the present
chapter, one read <specref ref="fund_syntax"/> 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
<specref ref="fund_xmlsyntax"/>, and the attribute value notations and
conventions described in <specref ref="fund_attval"/>.</p>
<p>The remainder of this section introduces MathML-specific
terminology and conventions used in this chapter.</p>
<div4><head>Types of presentation elements</head>
<p>The presentation elements are divided into two classes.
<emph>Token elements</emph> represent individual symbols, names,
numbers, labels, etc. In general, tokens can have only
characters as content. The
only exceptions are the vertical alignment element <kw
role="element">malignmark</kw>, <kw role="element">mglyph</kw>,
and entity references.
<emph>Layout schemata</emph> 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.</p>
<p>All individual <quote>symbols</quote> 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 <quote>string literals</quote> for compatibility with
computer algebra systems. Note that although a token element
represents a single meaningful <quote>symbol</quote> (name, number, label,
mathematical symbol, etc.), such symbols may be comprised of more than
one character. For example <code>sin</code> and <code>24</code> are
represented by the single tokens <code><mi>sin</mi></code>
and <code><mn>24</mn></code> respectively.</p>
<p>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 <quote>expression
constructors</quote>. 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 <quote>laying out</quote> its sub-expressions to form a larger
expression in traditional mathematical typesetting.</p>
</div4>
<div4><head>Terminology for other classes of elements and their relationships</head>
<p>The terminology used in this chapter for special classes of
elements, and for relationships between elements, is as follows: The
<emph>presentation elements</emph> are the MathML elements defined in
this chapter. These elements are listed in <specref
ref="presm_summary"/>. The <emph>content elements</emph> are the
MathML elements defined in <specref ref="contm"/>. The content elements are listed
in <specref ref="contm_elem"/>.</p>
<p>A MathML <emph>expression</emph> is a single instance of any of the
presentation elements with the exception of the empty elements <kw
role="element">none</kw> or <kw role="element">mprescripts</kw>, or is
a single instance of any of the content elements which are allowed as
content of presentation elements (described in <specref
ref="mixing_cminpm"/>). A <emph>sub-expression</emph> of an expression
<mi>E</mi> is any MathML expression that is part of the content of
<mi>E</mi>, whether <emph>directly</emph> or <emph>indirectly</emph>,
i.e. whether it is a <quote>child</quote> of <mi>E</mi> or not.</p>
<p>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 <emph>argument</emph> 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 elements that are its
arguments. </p>
</div4>
</div3>
<div3 id="presm_reqarg"><head>Required Arguments</head>
<p>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.</p>
<p>Note that MathML elements encoding rendered space <emph>do</emph>
count as arguments of the elements in which they appear. See <specref
ref="presm_mspace"/> for a discussion of the proper use of such
space-like elements.</p>
<div4><head>Inferred <kw role="element">mrow</kw>s</head>
<p>The elements listed in the following table as requiring 1*
argument (<kw role="element">msqrt</kw>, <kw role="element">mstyle</kw>,
<kw role="element">merror</kw>, <kw role="element">menclose</kw>, <kw
role="element">mpadded</kw>,
<kw role="element">mphantom</kw>, <kw role="element">mtd</kw>,
and <kw role="element">math</kw>) 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
<emph>inferred</emph> <kw role="element">mrow</kw> formed from all
their arguments. Although the <kw role="element">math</kw> element is
not a presentation element, it is listed below for completeness.</p>
<p>For example,
<eg role='mathml-fragment'><![CDATA[
<mtd>
</mtd>
]]></eg>
is treated as if it were
<eg role='mathml-fragment'><![CDATA[
<mtd>
<mrow>
</mrow>
</mtd>
]]></eg>
and
<eg role='mathml'><![CDATA[
<msqrt>
<mo> - </mo>
<mn> 1 </mn>
</msqrt>
]]></eg>
is treated as if it were
<eg role='mathml'><![CDATA[
<msqrt>
<mrow>
<mo> - </mo>
<mn> 1 </mn>
</mrow>
</msqrt>
]]></eg>
</p>
<p>This feature allows MathML data not to contain (and its authors to
leave out) many <kw role="element">mrow</kw> elements that would otherwise be
necessary.</p>
<p>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 <kw role="element">mrow</kw>
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.</p>
</div4>
<div4><head>Table of argument requirements</head>
<p>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 <kw
role="element">mrow</kw> as described above.
<table border="1">
<thead>
<tr>
<td>Element</td>
<td>Required argument count</td>
<td>Argument roles (when these differ by position)</td>
</tr>
</thead>
<tbody>
<tr>
<td><intref ref="presm_mrow"><kw role="element">mrow</kw></intref></td>
<td>0 or more</td>
<td></td>
</tr>
<tr>
<td><intref ref="presm_mfrac"><kw role="element">mfrac</kw></intref></td>
<td>2</td>
<td><emph>numerator</emph> <emph>denominator</emph></td>
</tr>
<tr>
<td><intref ref="presm_mroot"><kw role="element">msqrt</kw></intref></td>
<td>1*</td>
<td></td>
</tr>
<tr>
<td><intref ref="presm_mroot"><kw role="element">mroot</kw></intref></td>
<td>2</td>
<td><emph>base</emph> <emph>index</emph></td>
</tr>
<tr>
<td><intref ref="presm_mstyle"><kw role="element">mstyle</kw></intref></td>
<td>1*</td>
<td></td>
</tr>
<tr>
<td><intref ref="presm_merror"><kw role="element">merror</kw></intref></td>
<td>1*</td>
<td></td>
</tr>
<tr>
<td><intref ref="presm_mpadded"><kw role="element">mpadded</kw></intref></td>
<td>1*</td>
<td></td>
</tr>
<tr>
<td><intref ref="presm_mphantom"><kw role="element">mphantom</kw></intref></td>
<td>1*</td>
<td></td>
</tr>
<tr>
<td><intref ref="presm_mfenced"><kw role="element">mfenced</kw></intref></td>
<td>0 or more</td>
<td></td>
</tr>
<tr>
<td><intref ref="presm_menclose"><kw role="element">menclose</kw></intref></td>
<td>1*</td>
<td></td>
</tr>
<tr>
<td><intref ref="presm_msub"><kw role="element">msub</kw></intref></td>
<td>2</td>
<td><emph>base</emph> <emph>subscript</emph></td>
</tr>
<tr>
<td><intref ref="presm_msup"><kw role="element">msup</kw></intref></td>
<td>2</td>
<td><emph>base</emph> <emph>superscript</emph></td>
</tr>
<tr>
<td><intref ref="presm_msubsup"><kw role="element">msubsup</kw></intref></td>
<td>3</td>
<td><emph>base</emph> <emph>subscript</emph> <emph>superscript</emph></td>
</tr>
<tr>
<td><intref ref="presm_munder"><kw role="element">munder</kw></intref></td>
<td>2</td>
<td><emph>base</emph> <emph>underscript</emph></td>
</tr>
<tr>
<td><intref ref="presm_mover"><kw role="element">mover</kw></intref></td>
<td>2</td>
<td><emph>base</emph> <emph>overscript</emph></td>
</tr>
<tr>
<td><intref ref="presm_munderover"><kw role="element">munderover</kw></intref></td>
<td>3</td>
<td><emph>base</emph> <emph>underscript</emph> <emph>overscript</emph></td>
</tr>
<tr>
<td><intref ref="presm_mmultiscripts"><kw role="element">mmultiscripts</kw></intref></td>
<td>1 or more</td>
<td><emph>base</emph>
(<emph>subscript</emph> <emph>superscript</emph>)*
[<kw role="emptytag">mprescripts</kw>
(<emph>presubscript</emph> <emph>presuperscript</emph>)*]</td>
</tr>
<tr>
<td><intref ref="presm_mtable"><kw role="element">mtable</kw></intref></td>
<td>0 or more rows</td>
<td>0 or more <kw role="element">mtr</kw> or <kw
role="element">mlabeledtr</kw> elements</td>
</tr>
<tr>
<td><intref ref="presm_mlabeledtr"><kw role="element">mlabeledtr</kw></intref></td>
<td>1 or more</td>
<td>a label and 0 or more <kw role="element">mtd</kw> elements</td>
</tr>
<tr>
<td><intref ref="presm_mtr"><kw role="element">mtr</kw></intref></td>
<td>0 or more</td>
<td>0 or more <kw role="element">mtd</kw> elements</td>
</tr>
<tr>
<td><intref ref="presm_mtd"><kw role="element">mtd</kw></intref></td>
<td>1*</td>
<td></td>
</tr>
<tr>
<td><intref ref="presm_maction"><kw role="element">maction</kw></intref></td>
<td>1 or more</td>
<td>depend on <kw role="attrib">actiontype</kw> attribute</td>
</tr>
<tr>
<td><intref ref="interf_toplevel"><kw role="element">math</kw></intref></td>
<td>1*</td>
<td></td>
</tr>
</tbody>
</table>
</p>
</div4>
</div3>
<div3><head>Elements with Special Behaviors</head>
<p>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.</p>
<p>Certain elements are considered space-like; these are defined in
<specref ref="presm_mspace"/>. This definition affects some of the suggested rendering
rules for <kw role="element">mo</kw> elements (<specref ref="presm_mo"/>).</p>
<p>Certain elements, e.g. <kw role="element">msup</kw>, are able to
embellish operators that are their first argument. These elements are
listed in <specref ref="presm_mo"/>, which precisely defines an <quote>embellished
operator</quote> and explains how this affects the suggested rendering rules
for stretchy operators.</p>
<p>Certain elements treat their arguments as the arguments of an
<quote>inferred <kw role="element">mrow</kw></quote> if they are not given
exactly one argument, as explained in <specref ref="presm_reqarg"/>.</p>
<p>In MathML 1.x, the <kw role="element">mtable</kw> element could infer
<kw role="element">mtr</kw> elements around its arguments, and the
<kw role="element">mtr</kw> element could infer
<kw role="element">mtd</kw> elements. In MathML 2.0, <kw
role="element">mtr</kw> and <kw role="element">mtd</kw> elements must
be explicit. However, for backward compatibility renderers may wish
to continue supporting inferred <kw role="element">mtr</kw> and <kw
role="element">mtd</kw> elements.
</p>
</div3>
<div3 id="presm_bidi"><head>Bidirectional Layout</head>
<p>The term 'bidirectional layout' refers to the fact that
letters from certain scripts, in particular Arabic and
Hebrew, are written from right to left, and that mixing
these with numbers or letters from scripts written left-
to-right results in text runs of two differing directions
within the same line or paragraph.</p>
<p>For ordinary text, Unicode defines a bidirectional algorithm
<bibref ref="Bidi"/>. This algorithm assumes that the order of
characters in a 'backing store' is in logical order (i.e. in the order
it would be pronounced or typed in), and defines how the characters
get reordered for display based on character properties and other
directives. HTML, CSS, XSL, and SVG adopt this algorithm and
provide ways to control it via markup or styling.</p>
<p>In mathematical expressions, bidirectional layout is more difficult
than it is in text. In part, this is due to the 2-dimensional nature
of mathematical layout, and the fact that spatial relationships are
often used to convey meaning in mathematics notation. Another factor is the
lack of established conventions for bidirectional mathematics layout, since
this is relatively uncommon, even in right-to-left contexts.</p>
<p>For these reasons, MathML 2.0 only adopts a restricted version of
the Unicode Bidirectional algorithm, as described in the remainder of
this section.</p>
<div4><head>Bidirectional Layout in Token Elements</head>
<p>For MathML token elements that can contain text (<kw
role="element">mtext</kw>, <kw role="element">mo</kw>, <kw
role="element">mi</kw>, <kw role="element">mn</kw> and <kw
role="element">ms</kw>), the <emph>implicit part</emph> of the Unicode
bidirectional algorithm <bibref ref="Bidi"/> is applied when its
content is rendered visually (i.e. characters are reordered based on
character properties). The base directionality is left-to-right.</p>
<p>The implicit part of the Unicode bidirectional algorithm
is identical to straightforward left-to-right layout if
there is only one character, or if there are no strong
right-to-left characters (i.e. no characters from the
Arabic, Hebrew, or similar scripts).</p>
<p>Applications are not required to apply the Unicode bidirectional
algorithm if they do not render strong right-to-left characters.
</p>
<p>Please note that for the transfinite cardinals represented
by Hebrew characters, the codepoints U+2135-U+2138 (ALEF SYMBOL,
BET SYMBOL, GIMEL SYMBOL, DALET SYMBOL) should be used.
These are strong left-to-right.</p>
</div4>
<div4><head>Bidirectional Layout of Mathematics Formulas</head>
<p>MathML 2.0 does not address right-to-left or bidirectional
layout in mathematics formulas. Only left-to-right layout is
supported. Right-to-left layout of mathematical formulas
may be addressed in a future version of MathML.</p>
</div4>
</div3>
<div3 id="presm_summary"><head>Summary of Presentation Elements</head>
<div4><head>Token Elements</head>
<table border="1">
<tbody>
<tr>
<td><intref ref="presm_mi"><kw role="element">mi</kw></intref></td>
<td>identifier</td>
</tr>
<tr>
<td><intref ref="presm_mn"><kw role="element">mn</kw></intref></td>
<td>number</td>
</tr>
<tr>
<td><intref ref="presm_mo"><kw role="element">mo</kw></intref></td>
<td>operator, fence, or separator</td>
</tr>
<tr>
<td><intref ref="presm_mtext"><kw role="element">mtext</kw></intref></td>
<td>text</td>
</tr>
<tr>
<td><intref ref="presm_mspace"><kw role="element">mspace</kw></intref></td>
<td>space</td>
</tr>
<tr>
<td><intref ref="presm_ms"><kw role="element">ms</kw></intref></td>
<td>string literal</td>
</tr>
<tr>
<td><intref ref="presm_mglyph"><kw role="element">mglyph</kw></intref></td>
<td>adding new character glyphs to MathML</td>
</tr>
</tbody>
</table>
</div4>
<div4><head>General Layout Schemata</head>
<table border="1">
<tbody>
<tr>
<td><intref ref="presm_mrow"><kw role="element">mrow</kw></intref></td>
<td>group any number of sub-expressions horizontally</td>
</tr>
<tr>
<td><intref ref="presm_mfrac"><kw role="element">mfrac</kw></intref></td>
<td>form a fraction from two sub-expressions</td>
</tr>
<tr>
<td><intref ref="presm_mroot"><kw role="element">msqrt</kw></intref></td>
<td>form a square root (radical without an index)</td>
</tr>
<tr>
<td><intref ref="presm_mroot"><kw role="element">mroot</kw></intref></td>
<td>form a radical with specified index</td>
</tr>
<tr>
<td><intref ref="presm_mstyle"><kw role="element">mstyle</kw></intref></td>
<td>style change</td>
</tr>
<tr>
<td><intref ref="presm_merror"><kw role="element">merror</kw></intref></td>
<td>enclose a syntax error message from a preprocessor</td>
</tr>
<tr>
<td><intref ref="presm_mpadded"><kw role="element">mpadded</kw></intref></td>
<td>adjust space around content</td>
</tr>
<tr>
<td><intref ref="presm_mphantom"><kw role="element">mphantom</kw></intref></td>
<td>make content invisible but preserve its size</td>
</tr>
<tr>
<td><intref ref="presm_mfenced"><kw role="element">mfenced</kw></intref></td>
<td>surround content with a pair of fences</td>
</tr>
<tr>
<td><intref ref="presm_menclose"><kw role="element">menclose</kw></intref></td>
<td>enclose content with a stretching symbol such as a long division sign.</td>
</tr>
</tbody>
</table>
</div4>
<div4><head>Script and Limit Schemata</head>
<table border="1">
<tbody>
<tr>
<td><intref ref="presm_msub"><kw role="element">msub</kw></intref></td>
<td>attach a subscript to a base</td>
</tr>
<tr>
<td><intref ref="presm_msup"><kw role="element">msup</kw></intref></td>
<td>attach a superscript to a base</td>
</tr>
<tr>
<td><intref ref="presm_msubsup"><kw role="element">msubsup</kw></intref></td>
<td>attach a subscript-superscript pair to a base</td>
</tr>
<tr>
<td><intref ref="presm_munder"><kw role="element">munder</kw></intref></td>
<td>attach an underscript to a base</td>
</tr>
<tr>
<td><intref ref="presm_mover"><kw role="element">mover</kw></intref></td>
<td>attach an overscript to a base</td>
</tr>
<tr>
<td><intref ref="presm_munderover"><kw role="element">munderover</kw></intref></td>
<td>attach an underscript-overscript pair to a base</td>
</tr>
<tr>
<td><intref ref="presm_mmultiscripts"><kw role="element">mmultiscripts</kw></intref></td>
<td>attach prescripts and tensor indices to a base</td>
</tr>
</tbody>
</table>
</div4>
<div4><head>Tables and Matrices</head>
<table border="1">
<tbody>
<tr>
<td><intref ref="presm_mtable"><kw role="element">mtable</kw></intref></td>
<td>table or matrix</td>
</tr>
<tr>
<td><intref ref="presm_mlabeledtr"><kw role="element">mlabeledtr</kw></intref></td>
<td>row in a table or matrix with a label or equation number</td>
</tr>
<tr>
<td><intref ref="presm_mtr"><kw role="element">mtr</kw></intref></td>
<td>row in a table or matrix</td>
</tr>
<tr>
<td><intref ref="presm_mtd"><kw role="element">mtd</kw></intref></td>
<td>one entry in a table or matrix</td>
</tr>
<tr>
<td>
<intref ref="presm_malign"><kw role="element">maligngroup</kw></intref> and
<intref ref="presm_malign"><kw role="element">malignmark</kw></intref></td>
<td>alignment markers</td>
</tr>
</tbody>
</table>
</div4>
<div4><head>Enlivening Expressions</head>
<table border="1">
<tbody>
<tr>
<td><intref ref="presm_maction"><kw role="element">maction</kw></intref></td>
<td>bind actions to a sub-expression</td>
</tr>
</tbody>
</table>
</div4>
</div3>
</div2>
<div2 id="presm_tokel"><head>Token Elements</head>
<p>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.</p>
<p>Frequently tokens consist of a single character denoting a
mathematical symbol. Other cases, e.g. function names, involve
multi-character tokens. Further, because traditional mathematical
notation makes wide use of symbols distinguished by their
typographical properties (e.g. a Fraktur 'g' for a Lie algebra, or a
bold 'x' for a vector), care must be taken to insure that styling
mechanisms respect typographical properties which carry meaning.
Consequently, characters, tokens, and typographical properties of
symbols are closely related to one another in MathML.
</p>
<div3 id="presm_tokenchars"><head>MathML characters in
token elements</head>
<p>Character data in MathML markup is only allowed to occur as part of
the content of token elements. The only exception is whitespace
between elements, which is ignored. Token elements can
contain any sequence of zero or more Unicode characters. 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 exceptions to this are
the empty elements <kw role="element">mspace</kw> and
<kw role="element">mglyph</kw>.
The <kw role="element">mspace</kw> element's width depends upon
its attribute values.
The <kw role="element">mglyph</kw> element
renders using the character described by its attributes.</p>
<p>While all Unicode character data is valid in token element content, MathML
2.0 distinguishes a special subset of named Unicode 3.2 characters,
called MathML characters in this document.
The complete list of MathML characters is defined in
<specref ref="chars"/>. MathML characters can be either represented
directly as Unicode character data, or indirectly via numeric or
character entity references. See <specref ref="chars"/> for a
discussion of the advantages and disadvantages of numeric
character references versus
entity references. New mathematics characters that arise, or non-standard
glyphs for existing MathML characters, may be represented by means of
the <kw role="element">mglyph</kw> element.</p>
<p>Apart from the <kw role="element">mglyph</kw> element, the <kw
role="element">malignmark</kw> element is the only other element
allowed in the content of tokens. See <specref ref="presm_malign"/>
for details.</p>
<p>Token elements (other than <kw role="element">mspace</kw> and
<kw role="element">mglyph</kw>) 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). Rendering algorithms should also take into account the
mathematics style attributes as described below, and modify surrounding
spacing by rules or attributes specific to each type of token
element.</p>
<div4 id="presm_symbolchars"><head>Alphanumeric symbol
characters</head>
<p>A large class of mathematical symbols are single letter identifiers
typically used as variable names in formulas. Different font variants
of a letter are treated as separate symbols. For example, a Fraktur
'g' might denote a Lie algebra, while a Roman 'g' denotes the
corresponding Lie group. These letter-like symbols are traditionally
typeset differently than the same characters appearing in text, using
different spacing and ligature conventions. These characters must
also be treated specially by style mechanisms, since arbitrary style
transformations can change meaning in an expression. </p>
<p>For these reasons, Unicode 3.1 will be adding more than nine
hundred Math Alphanumeric Symbol characters corresponding to letter-like
symbols. These characters are in the Secondary Multilingual Plane
(SMP). See <specref ref="chars"/> for more information.
As valid Unicode data, these characters are permitted in MathML 2.0, and as
tools and fonts for them become widely available, we anticipate they
will be the predominant way of denoting letter-like symbols.</p>
<p>Until support for SMP characters is widely available, however, it
is still necessary to provide an alternative encoding using only Basic
Multilingual Plane (BMP) characters together with markup. MathML 2.0
defines a correspondence between token elements with certain
combinations of BMP character data and the <kw
role="attrib">mathvariant</kw> attribute and tokens containing SMP
Math Alphanumeric Symbol characters. Processing applications that accept SMP
characters are required to treat the corresponding BMP and attribute
combinations identically. The next section discusses the <kw
role="attrib">mathvariant</kw> attribute in more detail, and a
complete technical description of the corresponding characters is given in
<specref ref="chars_BMP-SMP"/>.</p>
</div4>
</div3>
<div3 id="presm_commatt"><head>Mathematics style attributes common to token
elements</head>
<p>MathML 2.0 introduces four new <emph>mathematics style</emph> attributes.
These attributes are valid on all presentation token elements except
<kw role="element">mspace</kw> and <kw role="element">mglyph</kw>, and
on no other elements except <kw role="element">mstyle</kw>. The attributes
are:
<table border="1">
<thead>
<tr>
<td>Name</td>
<td>values</td>
<td>default</td>
</tr>
</thead>
<tbody>
<tr>
<td>mathvariant</td>
<td>
normal | bold | italic | bold-italic | double-struck |
bold-fraktur | script | bold-script |
fraktur | sans-serif | bold-sans-serif | sans-serif-italic |
sans-serif-bold-italic | monospace</td>
<td>normal (<emph>except on</emph> <kw role="starttag">mi</kw>)</td>
</tr>
<tr>
<td>mathsize</td>
<td>small | normal | big | number v-unit</td>
<td>inherited</td>
</tr>
<tr>
<td>mathcolor</td>
<td>#rgb | #rrggbb | html-color-name</td>
<td>inherited</td>
</tr>
<tr>
<td>mathbackground</td>
<td>#rgb | #rrggbb | html-color-name</td>
<td>inherited</td>
</tr>
</tbody>
</table>
</p>
<p>(See <specref ref="fund_attval"/> for terminology and
notation used in attribute value descriptions.)</p>
<p>The mathematics style attributes define logical classes of token
elements. Each class is intended to correspond to a collection of
typographically-related symbolic tokens that have a meaning within a
given math expression, and therefore need to be visually distinguished
and protected from inadvertent document-wide style changes which might
change their meanings.</p>
<p>When MathML rendering takes place in an environment where CSS is
available, the mathematics style attributes can be viewed as
predefined selectors for CSS style rules. See <specref
ref="interf_style"/> and <specref ref="stylesheet"/> for further
discussion and a sample CSS style sheet. When CSS is not available,
it is up to the internal style mechanism of the rendering application
to visually distinguish the different logical classes.</p>
<p>At a theoretical level, renderers have complete freedom in
mapping mathematics style attributes to specific rendering properties.
However, in practice, the mathematics style attribute names and values
suggest obvious typographical properties, and renderers should attempt
to respect these natural interpretations as far as possible. For
example, it is reasonable to render a token with the <kw
role="attrib">mathvariant</kw> attribute set to <kw
role="attval">sans-serif</kw> in Helvetica or Arial. However,
rendering the token in a Times Roman font could
be seriously misleading and should be avoided. </p>
<p>A issue arises in that the natural interpretations of the <kw
role="attrib">mathvariant</kw> attribute values only make sense for
certain characters. For example, there is no clear cut rendering for
a 'fraktur' alpha, or a 'bold italic' Kanji character. In general,
the only cases that have a clear interpretation are exactly the ones
that correspond to SMP Math Alphanumeric Symbol characters.</p>
<p>Consequently, style sheet authors and application developers are
encouraged in the strongest possible terms to respect the obvious
typographical interpretation of the <kw role="attrib">mathvariant</kw>
attribute when applied to characters that have SMP Math Alphanumeric Symbol
counterparts. In all other cases, it is up to the renderer to
determine what effect, if any, the <kw role="attrib">mathvariant</kw>
attribute will have. For example, a renderer might sensibly choose to
display a token with the contents <kw role="entity">sum</kw> (a
character with no SMP counterpart) in bold face font if it has the <kw
role="attrib">mathvariant</kw> attribute set to <kw
role="attval">bold</kw> or to <kw role="attval">bold-fraktur</kw>, and
to display it in a default Roman font if the <kw
role="attrib">mathvariant</kw> attribute is set to <kw
role="attval">fraktur</kw>. As this example indicates, authors should
refrain from using the <kw role="attrib">mathvariant</kw>
attribute with characters that do not have SMP counterparts, since
renderings may not be useful or predictable.</p>
<p>Finally, there is a redundancy problem with the <kw
role="attrib">mathvariant</kw> attribute that must be dealt with as a
special case. When the <kw role="attrib">mathvariant</kw> attribute
is used on an <kw role="element">mi</kw> element containing a single
character from the specific ranges of BMP character data detailed in
<specref ref="chars_BMP-SMP"/>, the resulting rendering
will be visually indistinguishable from an <kw role="element">mi</kw>
element with no attributes containing the corresponding SMP
character. Therefore MathML 2.0 mandates that processing applications
treat these two representations as equivalent. This is primarily an
issue for applications that support searching and/or equality
testing.</p>
<p>Token elements also permit <kw role="attrib">id</kw>,
<kw role="attrib">xref</kw>, <kw role="attrib">class</kw> and
<kw role="attrib">style</kw>
attributes for compatibility with style sheet
mechanisms, as described in <specref ref="fund_globatt"/>.
However, some care must be taken when using CSS generally. Using CSS to
produce visual effects that alter the meaning of an equation should be
especially avoided, since MathML is used in many non-CSS environments.
Similarly, care should be taken to insure arbitrary document-wide
style transformations do not affect mathematics expressions in such a way
that meaning is altered.</p>
<p>Since MathML expressions are often embedded in a textual data
format such as XHTML, the surrounding text and the MathML must share
rendering attributes such as font size, so that the renderings will be
compatible in style. For this reason, most attribute values affecting
text rendering are inherited from the rendering environment, as shown
in the <quote>default</quote> column in the table above. (In
cases where the surrounding text and the MathML are being rendered by
separate software, e.g. a browser and a plug-in, it is also important
for the rendering environment to provide the MathML renderer with
additional information, such as the baseline position of surrounding
text, which is not specified by any MathML attributes.)
Note, however, that MathML 2.0 doesn't specify the mechanism by which
style information is inherited from the rendering environment.
For example, one browser plug-in might choose to rely
completely on the CSS inheritance mechanism and use the fully resolved
CSS properties for rendering, while another application might only consult
a style environment at the root node, and then use its own internal style
inheritance rules.</p>
<p>Most MathML renderers will probably want to rely on some degree to
additional, internal style processing algorithms. In particular,
inheritance of the <kw role="attrib">mathvariant</kw> attribute does
not follow the CSS model. The default value for this attribute is <kw
role="attval">normal</kw> (non-slanted) for all tokens except
<kw role="element">mi</kw>.
For <kw role="element">mi</kw> tokens, the default depends on the number of
characters in tokens' content. (The <intref
ref="interf_deprec">deprecated</intref> <kw
role="attrib">fontslant</kw> attribute also behaves this way.) See
<specref ref="presm_mi"/> for details.
</p>
<div4 id="presm_deprecatt"><head>Deprecated style attributes on token
elements</head>
<p>The MathML 1.01 style attributes listed below have been <intref
ref="interf_deprec">deprecated</intref> in MathML 2.0. In
rendering environments that support CSS, it is preferable to use CSS
to control the rendering properties corresponding to these attributes.
However as explained above, direct manipulation of these rendering
properties by whatever means should usually be avoided.</p>
<p>If both a new mathematics style attribute and conflicting deprecated
attributes are given, the new math style attribute value should be
used. For example
<eg role='mathml'><![CDATA[
<mi fontweight='bold' mathvariant='normal'> a </mi>
]]></eg>
should render in a normal weight font, and
<eg role='mathml'><![CDATA[
<mi fontweight='bold' mathvariant='sans-serif'> a </mi>
]]></eg>
should render in a normal weight sans serif font. In the example
<eg role='mathml'><![CDATA[
<mi fontweight='bold' mathvariant='fraktur'> a1 </mi>
]]></eg>
the <kw role="attrib">mathvariant</kw> attribute still overrides <kw
role="attrib">fontweight</kw> attribute, even though <kw
role="attval">fraktur</kw> generally shouldn't be applied to a '1'
since there is no corresponding SMP Math Alphanumeric Symbol
character. In the absence of fonts containing Fraktur digits,
this would probably render as a Fraktur 'a' followed by a Roman '1' in
most renderers.</p>
<p>The new mathematics style attributes also override deprecated 1.01
style attribute values that are inherited. Thus
<eg role='mathml'><![CDATA[
<mstyle fontstyle='italic'>
<mi mathvariant='bold'> a </mi>
</mstyle>
]]></eg>
renders in a bold upright font, not a bold italic font.</p>
<p>At the same time, the MathML 1.01 attributes still serve a
purpose. Since they correspond directly to rendering properties needed
for mathematics layout, they are very useful for describing MathML layout
rules and algorithms. For this reason, and for backward compatibility,
the MathML rendering rules suggested in this chapter continue to be
described in terms of the rendering properties described by these
MathML 1.01 style attributes.</p>
<p>The deprecated attributes are:
<table border="1">
<thead>
<tr>
<td>Name</td>
<td>values</td>
<td>default</td>
</tr>
</thead>
<tbody>
<tr>
<td>fontsize</td>
<td>number v-unit</td>
<td>inherited</td>
</tr>
<tr>
<td>fontweight</td>
<td>normal | bold</td>
<td>inherited</td>
</tr>
<tr>
<td>fontstyle</td>
<td>normal | italic</td>
<td>normal (<emph>except on</emph> <kw role="starttag">mi</kw>)</td>
</tr>
<tr>
<td>fontfamily</td>
<td>string | css-fontfamily</td>
<td>inherited</td>
</tr>
<tr>
<td>color</td>
<td>#rgb | #rrggbb | html-color-name</td>
<td>inherited</td>
</tr>
</tbody>
</table>
</p>
<p>The <kw role="attrib">fontsize</kw> attribute specifies the desired
font size. <kw role="attrib">v-unit</kw> represents a unit of
vertical length (see <specref ref="fund_cssatt"/>). The most common
unit for specifying font sizes in typesetting is <code>pt</code>
(points).</p>
<p>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.</p>
<p>Many MathML elements automatically change <kw
role="attrib">fontsize</kw> in some of their children; see the
discussion of <kw role="attrib">scriptlevel</kw> in the section on <kw
role="element">mstyle</kw>, <specref ref="presm_mstyle"/>.</p>
<p>The value of the <kw role="attrib">fontfamily</kw> 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 <kw role="attrib">css-fontfamily</kw>
below). (Note that the renderer's mechanism for finding fonts by name
may be case-sensitive.)</p>
<p>If the value of <kw role="attrib">fontfamily</kw> 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.</p>
<p>Note that any use of the <kw role="attrib">fontfamily</kw>
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 a non-ASCII MathML character (for example, by using a
reference to a character in some symbol font that maps ordinary
characters to glyphs for non-ASCII characters). As a corollary to this
principle, MathML renderers should attempt to always produce
intelligible renderings for the MathML characters listed in <specref
ref="chars"/>, 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 <specref ref="chars"/>.</p>
<p>The symbol <kw role="attrib">css-fontfamily</kw> refers to a legal
value for the <kw role="attrib">font-family</kw> property in CSS,
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 CSS<bibref ref="CSS2"/>.
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 <specref
ref="fund_cssatt"/>).</p>
</div4>
<div4 id="presm_color"><head>Color-related attributes</head>
<p>The <kw role="attrib">mathcolor</kw> (and deprecated <kw role="attrib">color</kw>) attribute controls the color in which the
content of tokens is rendered. Additionally, when inherited from
<kw role="element">mstyle</kw> or from a MathML expression's rendering
environment, it controls the color of all other drawing by MathML
elements, including the lines or radical signs that can be drawn by
<kw role="element">mfrac</kw>, <kw role="element">mtable</kw>, or
<kw role="element">msqrt</kw>.</p>
<p>The values of
<kw role="attrib">mathcolor</kw>,
<kw role="attrib">color</kw>,
<kw role="attrib">mathbackground</kw>,
and <kw role="attrib">background</kw> can be specified as
a string consisting of '#' followed without intervening whitespace by
either 1-digit or 2-digit hexadecimal values for the red, green, and
blue components, respectively, of the desired color, with the same
number of digits used for each component (or as the keyword
<quote>transparent</quote> for <kw role="attrib">background</kw>). The hexadecimal digits are not
case-sensitive. The possible 1-digit values range from 0 (component
not present) to F (component fully present), and the possible 2-digit
values range from 00 (component not present) to FF (component fully
present), with the 1-digit value <mi>x</mi> being equivalent to the
2-digit value <emph>xx</emph> (rather than <emph>x0</emph>).
% <mi>x</mi>0 would be a more strictly correct notation,
but renders terribly in some browsers.</p>
<p>These attributes can also be specified as an
<kw role="attrib">html-color-name</kw>, which is defined below.</p>
<p>The color syntax described above is a subset of the syntax of the <kw
role="attrib">color</kw> and <kw role="attrib">background-color</kw>
properties of CSS. The <kw role="attrib">background-color</kw> syntax
is in turn a subset of the full CSS <kw role="attrib">background</kw>
property syntax, which also permits specification of (for example)
background images with optional repeats. The more general attribute name
<kw role="attrib">background</kw> is used in MathML to facilitate possible
extensions to the attribute's scope in future versions of MathML.</p>
<p>Color values on either attribute can also be specified as an <kw
role="attrib">html-color-name</kw>, that is, as one of the color-name
keywords defined in <bibref ref="HTML4"/>
(<kw role="attval">aqua</kw>,
<kw role="attval">black</kw>,
<kw role="attval">blue</kw>,
<kw role="attval">fuchsia</kw>,
<kw role="attval">gray</kw>,
<kw role="attval">green</kw>,
<kw role="attval">lime</kw>,
<kw role="attval">maroon</kw>,
<kw role="attval">navy</kw>,
<kw role="attval">olive</kw>,
<kw role="attval">purple</kw>,
<kw role="attval">red</kw>,
<kw role="attval">silver</kw>,
<kw role="attval">teal</kw>,
<kw role="attval">white</kw>, and
<kw role="attval">yellow</kw>).
Note that the color name keywords are not case-sensitive, unlike most
keywords in MathML attribute values for compatibility with CSS and HTML.</p>
<p>The suggested MathML visual rendering rules do not define the
precise extent of the region whose background is affected by using the
<kw role="attrib">background</kw> attribute on <kw role="element">mstyle</kw>,
except that, when <kw role="element">mstyle</kw>'s content does not have
negative dimensions and its drawing region is not overlapped by other
drawing due to surrounding negative spacing, this region should lie
behind all the drawing done to render the content of the
<kw role="element">mstyle</kw>, but should not lie behind any of the
drawing done to render surrounding expressions. The effect of overlap
of drawing regions caused by negative spacing on the extent of the
region affected by the <kw role="attrib">background</kw> attribute is not
defined by these rules.</p>
</div4>
</div3>
<div3 id="presm_mi"><head>Identifier (<kw role="element">mi</kw>)</head>
<div4><head>Description</head>
<p>An <kw role="element">mi</kw> element represents a symbolic name or
arbitrary text that should be rendered as an identifier. Identifiers
can include variables, function names, and symbolic constants.</p>
<p>Not all <quote>mathematical identifiers</quote> are represented by
<kw role="element">mi</kw> elements – for example, subscripted or primed
variables should be represented using <kw role="element">msub</kw> or
<kw role="element">msup</kw> respectively. Conversely, arbitrary text
playing the role of a <quote>term</quote> (such as an ellipsis in a summed series)
can be represented using an <kw role="element">mi</kw> element, as shown
in an example in <specref ref="presm_mixtextmath"/>.</p>
<p>It should be stressed that <kw role="element">mi</kw> 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 <kw role="element">mi</kw> 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 <kw role="element">ci</kw> in
<specref ref="contm"/>.</p>
</div4>
<div4><head>Attributes</head>
<p><kw role="element">mi</kw> elements accept the attributes listed in
<specref ref="presm_commatt"/>, but in one case with a different default value:
<table border="1">
<thead>
<tr>
<td>Name</td>
<td>values</td>
<td>default</td>
</tr>
</thead>
<tbody>
<tr>
<td>mathvariant</td>
<td>normal | bold | italic | bold-italic | double-struck |
bold-fraktur | script | bold-script |
fraktur | sans-serif | bold-sans-serif | sans-serif-italic |
sans-serif-bold-italic | monospace</td>
<td>(depends on content; described below)</td>
</tr>
<tr>
<td>fontstyle (<intref ref="interf_deprec">deprecated</intref>)</td>
<td>normal | italic</td>
<td>(depends on content; described below)</td>
</tr>
</tbody>
</table>
</p>
<p>A typical graphical renderer would render an <kw
role="element">mi</kw> element as the characters in its content, with
no extra spacing around the characters (except spacing associated with
neighboring elements). The default <kw role="attrib">mathvariant</kw>
and <kw role="attrib">fontstyle</kw> would (typically) be <kw
role="attval">normal</kw> (non-slanted) unless the content is a single
character, in which case it would be <kw
role="attval">italic</kw>. Note that this rule for <kw
role="attrib">mathvariant</kw> and <kw role="attrib">fontstyle</kw>
attributes is specific to <kw role="element">mi</kw> elements; the
default value for the <kw role="attrib">mathvariant</kw> and <kw
role="attrib">fontstyle</kw> attributes on other MathML token elements
is <kw role="attval">normal</kw>.</p>
<p>Note that for purposes of determining equivalences of Math
Alphanumeric Symbol
characters (See <specref ref="chars_BMP-SMP"/> and <specref
ref="presm_symbolchars"/>) the value of the <kw
role="attrib">mathvariant</kw> attribute should be resolved first,
including the special defaulting behavior described above.
</p>
</div4>
<div4><head>Examples</head>
<eg role='mathml'><![CDATA[
<mi> x </mi>
<mi> D </mi>
<mi> sin </mi>
<mi mathvariant='script'> L </mi>
<mi></mi>
]]></eg>
<p>An <kw role="element">mi</kw> element with no content is allowed;
<code><mi></mi></code> might, for example, be used by an
<quote>expression editor</quote> to represent a location in a MathML expression
which requires a <quote>term</quote> (according to conventional syntax for
mathematics) but does not yet contain one.</p>
<p>Identifiers include function names such as
<quote>sin</quote>. Expressions such as <quote>sin <mi>x</mi></quote>
should be written using the <kw role="entity">ApplyFunction</kw> operator
(which also has the short name <kw role="entity">af</kw>) as shown below;
see also the discussion of invisible operators in <specref
ref="presm_mo"/>.
<eg role='mathml'><![CDATA[
<mrow>
<mi> sin </mi>
<mo> ⁡ </mo>
<mi> x </mi>
</mrow>
]]></eg>
</p>
<p>Miscellaneous text that should be treated as a <quote>term</quote> can also be
represented by an <kw role="element">mi</kw> element, as in:
<eg role='mathml'><![CDATA[
<mrow>
<mn> 1 </mn>
<mo> + </mo>
<mi> ... </mi>
<mo> + </mo>
<mi> n </mi>
</mrow>
]]></eg>
</p>
<p>When an <kw role="element">mi</kw> is used in such exceptional
situations, explicitly setting the <kw role="attrib">fontstyle</kw> attribute
may give better results than the default behavior of some
renderers.</p>
<p>The names of symbolic constants should be represented as
<kw role="element">mi</kw> elements:
<eg role='mathml'><![CDATA[
<mi> π </mi>
<mi> ⅈ </mi>
<mi> ⅇ </mi>
]]></eg>
</p>
<p>Use of special entity references for such constants can simplify
the interpretation of MathML presentation elements.
See <specref ref="chars"/> for a complete list of character entity
references in MathML.</p>
</div4>
</div3>
<div3 id="presm_mn"><head>Number (<kw role="element">mn</kw>)</head>
<div4><head>Description</head>
<p>An <kw role="element">mn</kw> element represents a <quote>numeric
literal</quote> 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.</p>
<p>The mathematical concept of a <quote>number</quote> can be quite
subtle and involved, depending on the context. As a consequence, not all
mathematical numbers should be represented using <kw
role="element">mn</kw>; examples of mathematical numbers that should be
represented differently are shown below, and include
complex numbers, ratios of numbers shown as fractions, and names of numeric
constants.</p>
<p>Conversely, since <kw role="element">mn</kw> is a presentation
element, there are a few situations where it may desirable to include
arbitrary text in the content of an <kw role="element">mn</kw> 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 <kw role="element">mn</kw> 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 <kw role="element">cn</kw> in
<specref ref="contm"/>.</p>
</div4>
<div4><head>Attributes</head>
<p><kw role="element">mn</kw> elements accept the attributes listed in
<specref ref="presm_commatt"/>.</p>
<p>A typical graphical renderer would render an
<kw role="element">mn</kw> element as the characters of its content, with
no extra spacing around them (except spacing from neighboring elements
such as <kw role="element">mo</kw>). Unlike <kw role="element">mi</kw>,
<kw role="element">mn</kw> elements are (typically) rendered in an
unslanted font by default, regardless of their content.</p>
</div4>
<div4><head>Examples</head>
<eg role='mathml'><![CDATA[
<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>
]]></eg>
</div4>
<div4><head>Numbers that should <emph>not</emph> be written
using <kw role="element">mn</kw> alone</head>
<p>Many mathematical numbers should be represented using presentation
elements other than <kw role="element">mn</kw> alone; this includes
complex numbers, ratios of numbers shown as fractions, and
names of numeric constants. Examples of MathML representations of
such numbers include:
<eg role='mathml'><![CDATA[
<mrow>
<mn> 2 </mn>
<mo> + </mo>
<mrow>
<mn> 3 </mn>
<mo> ⁢ </mo>
<mi> ⅈ </mi>
</mrow>
</mrow>
<mfrac> <mn> 1 </mn> <mn> 2 </mn> </mfrac>
<mi> π </mi>
<mi> ⅇ </mi>
]]></eg>
</p>
</div4>
</div3>
<div3 id="presm_mo"><head>Operator, Fence, Separator or Accent
(<kw role="element">mo</kw>)</head>
<div4><head>Description</head>
<p>An <kw role="element">mo</kw> 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
<kw role="element">mo</kw> element. As a consequence, in MathML the list
of things that should <quote>render as an operator</quote> 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
<quote>absolute value</quote> bars, separators such as comma and semicolon, and
mathematical accents such as a bar or tilde over a symbol.</p>
<p>The term <quote>operator</quote> as used in the present chapter means
any symbol or notation that should render as an operator, and that is
therefore representable by an <kw role="element">mo</kw> element. That is,
the term <quote>operator</quote> includes any ordinary operator, fence,
separator, or accent unless otherwise specified or clear from the
context.</p>
<p>All such symbols are represented in MathML with <kw
role="element">mo</kw> 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 <kw role="attrib">fence</kw>, <kw
role="attrib">separator</kw> and <kw role="attrib">accent</kw>, which can be
used to distinguish these cases.</p>
<p>A key feature of the <kw role="element">mo</kw> element is that its
default attribute values are set on a case-by-case basis from an
<quote>operator dictionary</quote> as explained below. In particular, default
values for <kw role="attrib">fence</kw>, <kw role="attrib">separator</kw> and
<kw role="attrib">accent</kw> can usually be found in the operator dictionary
and therefore need not be specified on each <kw role="element">mo</kw>
element.</p>
<p>Note that some mathematical operators are represented not by <kw
role="element">mo</kw> elements alone, but by <kw role="element">mo</kw>
elements <quote>embellished</quote> with (for example) surrounding
superscripts; this is further described below. Conversely, as presentation
elements, <kw role="element">mo</kw> elements can contain arbitrary text,
even when that text has no standard interpretation as an operator; for an
example, see the discussion <quote>Mixing text and mathematics</quote> in
<specref ref="presm_mtext"/>. See also <specref ref="contm"/> for
definitions of MathML content elements that are guaranteed to have the
semantics of specific mathematical operators.</p>
</div4>
<div4><head>Attributes</head>
<p><kw role="element">mo</kw> elements accept the attributes listed in
<specref ref="presm_commatt"/>, and the additional attributes listed here.
Most attributes get their default values from the
<specref ref="presm_opdict"/>, as described later in this
section. When a dictionary entry is not found for a given
<kw role="element">mo</kw> element, the default value shown here in
parentheses is used.
<table border="1" id="presm_table-mo">
<thead>
<tr>
<td>Name</td>
<td>values</td>
<td>default</td>
</tr>
</thead>
<tbody>
<tr>
<td>form</td>
<td>prefix | infix | postfix</td>
<td>set by position of operator in an <kw role="element">mrow</kw> (rule given below);
used with <kw role="element">mo</kw> content to index operator dictionary</td>
</tr>
<tr>
<td>fence</td>
<td>true | false</td>
<td>set by dictionary (false)</td>
</tr>
<tr>
<td>separator</td>
<td>true | false</td>
<td>set by dictionary (false)</td>
</tr>
<tr>
<td>lspace</td>
<td>number h-unit | namedspace</td>
<td>set by dictionary (thickmathspace)</td>
</tr>
<tr>
<td>rspace</td>
<td>number h-unit | namedspace</td>
<td>set by dictionary (thickmathspace)</td>
</tr>
<tr>
<td>stretchy</td>
<td>true | false</td>
<td>set by dictionary (false)</td>
</tr>
<tr>
<td>symmetric</td>
<td>true | false</td>
<td>set by dictionary (true)</td>
</tr>
<tr>
<td>maxsize</td>
<td>number [ v-unit | h-unit ] | namedspace | infinity</td>
<td>set by dictionary (infinity)</td>
</tr>
<tr>
<td>minsize</td>
<td>number [ v-unit | h-unit ] | namedspace</td>
<td>set by dictionary (1)</td>
</tr>
<tr>
<td>largeop</td>
<td>true | false</td>
<td>set by dictionary (false)</td>
</tr>
<tr>
<td>movablelimits</td>
<td>true | false</td>
<td>set by dictionary (false)</td>
</tr>
<tr>
<td>accent</td>
<td>true | false</td>
<td>set by dictionary (false)</td>
</tr>
</tbody>
</table>
</p>
<p><kw role="attrib">h-unit</kw> represents a unit of horizontal
length, and <kw role="attrib">v-unit</kw> represents a unit of vertical
length (see
<specref ref="fund_units"/>).
<kw role="attrib">namedspace</kw> is one of
<kw role="attval">veryverythinmathspace</kw>,
<kw role="attval">verythinmathspace</kw>,
<kw role="attval">thinmathspace</kw>,
<kw role="attval">mediummathspace</kw>,
<kw role="attval">thickmathspace</kw>,
<kw role="attval">verythickmathspace</kw>, or
<kw role="attval">veryverythickmathspace</kw>.
These values can be set by using the <kw role="element">mstyle</kw> element
as is further discussed in <specref ref="presm_mstyle"/>.
</p>
<p>If no unit is given with <kw role="attrib">maxsize</kw> or <kw
role="attrib">minsize</kw>, 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.</p>
<p>Typical graphical renderers show all <kw role="element">mo</kw>
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.</p>
<p>Renderers without access to complete fonts for the MathML character
set may choose not to render an <kw role="element">mo</kw> element as
precisely the characters in its content in some cases. For example,
<code><![CDATA[<mo> ≤ </mo>]]></code> might be rendered as
<code><=</code> to a terminal. However, as a general rule,
renderers should attempt to render the content of an
<kw role="element">mo</kw> element as literally as possible.
That is,
<code><![CDATA[<mo> ≤ </mo>]]></code> and
<code><![CDATA[<mo> <= </mo>]]></code> should render differently.
(The first one should render as a single character
representing a less-than-or-equal-to sign, and the second one as the
two-character sequence <code><=</code>.)</p>
</div4>
<div4><head>Examples with ordinary operators</head>
<eg role='mathml'><![CDATA[
<mo> + </mo>
<mo> < </mo>
<mo> ≤ </mo>
<mo> <= </mo>
<mo> ++ </mo>
<mo> ∑ </mo>
<mo> .NOT. </mo>
<mo> and </mo>
<mo> ⁢ </mo>
<mo mathvariant='bold'> + </mo>
]]></eg>
</div4>
<div4><head>Examples with fences and separators</head>
<p>Note that the <kw role="element">mo</kw> elements in these examples
don't need explicit <kw role="attrib">fence</kw> or <kw
role="attrib">separator</kw> attributes, since these can be found using the
operator dictionary as described below. Some of these examples could also
be encoded using the <kw role="element">mfenced</kw> element described in
<specref ref="presm_mfenced"/>.</p>
<p>(<mi>a</mi>+<mi>b</mi>)
<eg role='mathml'><![CDATA[
<mrow>
<mo> ( </mo>
<mrow>
<mi> a </mi>
<mo> + </mo>
<mi> b </mi>
</mrow>
<mo> ) </mo>
</mrow>
]]></eg>
</p>
<p>[0,1)
<eg role='mathml'><![CDATA[
<mrow>
<mo> [ </mo>
<mrow>
<mn> 0 </mn>
<mo> , </mo>
<mn> 1 </mn>
</mrow>
<mo> ) </mo>
</mrow>
]]></eg>
</p>
<p><mi>f</mi>(<mi>x</mi>,<mi>y</mi>)
<eg role='mathml'><![CDATA[
<mrow>
<mi> f </mi>
<mo> ⁡ </mo>
<mrow>
<mo> ( </mo>
<mrow>
<mi> x </mi>
<mo> , </mo>
<mi> y </mi>
</mrow>
<mo> ) </mo>
</mrow>
</mrow>
]]></eg>
</p>
</div4>
<div4><head>Invisible operators</head>
<p>Certain operators that are <quote>invisible</quote> in traditional
mathematical notation should be represented using specific entity
references within <kw role="element">mo</kw> elements, rather than simply
by nothing. The entity references used for these <quote>invisible
operators</quote> are:
<table border="1">
<thead>
<tr>
<td>Full name</td>
<td>Short name</td>
<td>Examples of use</td>
</tr>
</thead>
<tbody>
<tr>
<td><kw role="entity">InvisibleTimes</kw></td>
<td><kw role="entity">it</kw></td>
<td><mi>x</mi><mi>y</mi></td>
</tr>
<tr>
<td><kw role="entity">ApplyFunction</kw></td>
<td><kw role="entity">af</kw></td>
<td><mi>f</mi>(<mi>x</mi>) sin <mi>x</mi></td>
</tr>
<tr>
<td><kw role="entity">InvisibleComma</kw></td>
<td><kw role="entity">ic</kw></td>
<td><mi>m</mi><sub>12</sub></td>
</tr>
</tbody>
</table>
</p>
<p>The MathML representations of the examples in the above table are:
<eg role='mathml'><![CDATA[
<mrow>
<mi> x </mi>
<mo> ⁢ </mo>
<mi> y </mi>
</mrow>
<mrow>
<mi> f </mi>
<mo> ⁡ </mo>
<mrow>
<mo> ( </mo>
<mi> x </mi>
<mo> ) </mo>
</mrow>
</mrow>
<mrow>
<mi> sin </mi>
<mo> ⁡ </mo>
<mi> x </mi>
</mrow>
<msub>
<mi> m </mi>
<mrow>
<mn> 1 </mn>
<mo> ⁣ </mo>
<mn> 2 </mn>
</mrow>
</msub>
]]></eg>
</p>
<p>The reasons for using specific <kw role="element">mo</kw> elements for
invisible operators include:
<ulist>
<item><p>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
<kw role="element">mspace</kw> or <kw role="element">mtext</kw>
elements;</p>
</item>
<item><p>these operators should often have specific audio renderings
different than that of the lack of any operator;</p>
</item>
<item><p>automatic semantic interpretation of MathML presentation elements
is made easier by the explicit specification of such operators.</p>
</item>
</ulist>
</p>
<p>For example, an audio renderer might render <mi>f</mi>(<mi>x</mi>)
(represented as in the above examples) by speaking <quote>f of x</quote>, but use
the word <quote>times</quote> in its rendering of <mi>x</mi><mi>y</mi>.
Although its rendering must still be different depending on the structure
of neighboring elements (sometimes leaving out <quote>of</quote> or
<quote>times</quote> entirely), its task is made much easier by the use of
a different <kw role="element">mo</kw> element for each invisible
operator.</p>
</div4>
<div4><head>Names for other special operators</head>
<p>MathML also includes <kw role="entity">DifferentialD</kw> for use
in an <kw role="element">mo</kw> element representing the differential
operator symbol usually denoted by <quote>d</quote>. 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. </p>
</div4>
<div4><head>Detailed rendering rules for <kw role="element">mo</kw> elements</head>
<p>Typical visual rendering behaviors for <kw role="element">mo</kw>
elements are more complex than for the other MathML token elements, so
the rules for rendering them are described in this separate
subsection.</p>
<p>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.</p>
<div5 id="presm_opdict"><head>The operator dictionary</head>
<p>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 <kw role="element">mo</kw> elements with specific
contents and a specific <kw role="attrib">form</kw> attribute. Since these
defaults vary from symbol to symbol, MathML anticipates that renderers
will have an <quote>operator dictionary</quote> of default attributes for
<kw role="element">mo</kw> elements (see <specref ref="oper-dict"/>) indexed by each
<kw role="element">mo</kw> element's content and <kw role="attrib">form</kw>
attribute. If an <kw role="element">mo</kw> element is not listed in the
dictionary, the default values shown in parentheses in the table of
attributes for <kw role="element">mo</kw> should be used, since these
values are typically acceptable for a generic operator.</p>
<p>Some operators are <quote>overloaded</quote>, 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, <quote>+</quote> 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 <kw role="attrib">form</kw> 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.</p>
</div5>
<div5 id="presm_formdefval"><head>Default value of the
<kw role="attrib">form</kw> attribute</head>
<p>The <kw role="attrib">form</kw> attribute does not usually have to be
specified explicitly, since there are effective heuristic rules for
inferring the value of the <kw role="attrib">form</kw> attribute from the
context. If it is not specified, and there is more than one possible
form in the dictionary for an <kw role="element">mo</kw> element with
given content, the renderer should choose which form to use as follows
(but see the exception for embellished operators, described later):
<ulist>
<item><p>If the operator is the first argument in an <kw
role="element">mrow</kw> of length (i.e. number of arguments) greater than
one (ignoring all space-like arguments (see <specref ref="presm_mspace"/>) in the
determination of both the length and the first argument), the prefix form
is used;</p>
</item>
<item><p>if it is the last argument in an <kw role="element">mrow</kw> of
length greater than one (ignoring all space-like arguments), the postfix
form is used;</p>
</item>
<item><p>in all other cases, including when the operator is not part of an
<kw role="element">mrow</kw>, the infix form is used.</p>
</item>
</ulist>
</p>
<p>Note that these rules make reference to the
<kw role="element">mrow</kw> in which the <kw role="element">mo</kw>
element lies. In some situations, this <kw role="element">mrow</kw>
might be an inferred <kw role="element">mrow</kw> implicitly present
around the arguments of an element such as
<kw role="element">msqrt</kw> or <kw role="element">mtd</kw>.</p>
<p>Opening (left) fences should have <kw role="attrib">form</kw>="prefix",
and closing (right) fences should have <kw role="attrib">form</kw>="postfix";
separators are usually <quote>infix</quote>, but not always,
depending on their surroundings. As with ordinary operators,
these values do not usually need to be specified explicitly.</p>
<p>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 <kw role="element">mo</kw> element content, the
renderer should use the defaults given in parentheses in the table of
attributes for <kw role="element">mo</kw>.</p>
</div5>
<div5><head>Exception for embellished operators</head>
<p>There is one exception to the above rules for choosing an <kw
role="element">mo</kw> element's default <kw role="attrib">form</kw>
attribute. An <kw role="element">mo</kw> element that is
<quote>embellished</quote> 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 <kw role="element">mrow</kw> is examined by the above
rules and whose surrounding spacing is affected by its form, not the <kw
role="element">mo</kw> element at its core; however, the attributes
influencing this surrounding spacing are taken from the <kw
role="element">mo</kw> element at the core (or from that element's
dictionary entry).</p>
<p>For example, the <quote>+<sub>4</sub></quote> in
<mi>a</mi>+<sub>4</sub><mi>b</mi>
should be considered an infix operator as a whole, due to its position
in the middle of an <kw role="element">mrow</kw>, but its rendering
attributes should be taken from the <kw role="element">mo</kw> element
representing the <quote>+</quote>, or when those are not specified explicitly,
from the operator dictionary entry for <code><mo form="infix"> +
</mo></code>.
The precise definition of an <quote>embellished operator</quote> is:
<ulist>
<item><p>an <kw role="element">mo</kw> element;</p>
</item>
<item><p>or one of the elements
<kw role="element">msub</kw>,
<kw role="element">msup</kw>,
<kw role="element">msubsup</kw>,
<kw role="element">munder</kw>,
<kw role="element">mover</kw>,
<kw role="element">munderover</kw>,
<kw role="element">mmultiscripts</kw>,
<kw role="element">mfrac</kw>, or
<kw role="element">semantics</kw>
(<specref ref="contm_synsem"/>), whose first argument exists and is an embellished
operator;</p>
</item>
<item><p>or one of the elements
<kw role="element">mstyle</kw>,
<kw role="element">mphantom</kw>, or
<kw role="element">mpadded</kw>,
such that an <kw role="element">mrow</kw> containing the same
arguments would be an embellished operator;</p>
</item>
<item><p>or an <kw role="element">maction</kw> element whose selected
sub-expression exists and is an embellished operator;</p> </item>
<item><p>or an <kw role="element">mrow</kw> whose arguments consist (in any order)
of one embellished operator and zero or more space-like elements.</p>
</item>
</ulist>
Note that this definition permits nested embellishment only when
there are no intervening enclosing elements not in the above list.</p>
<p>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 <kw role="attrib">form</kw>
attribute.</p>
</div5>
<div5><head>Rationale for definition of embellished operators</head>
<p>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.</p>
<p>An <kw role="element">mfrac</kw> is included as an
<quote>embellisher</quote> because of the common notation for a
differential operator:
<eg role='mathml'><![CDATA[
<mfrac>
<mo> ⅆ </mo>
<mrow>
<mo> ⅆ </mo>
<mi> x </mi>
</mrow>
</mfrac>
]]></eg>
</p>
<p>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 <kw role="element">mo</kw> element.</p>
<p>Note that an <kw role="element">mrow</kw> containing a single argument
is an embellished operator if and only if its argument is an embellished
operator. This is because an <kw role="element">mrow</kw> with a single
argument must be equivalent in all respects to that argument alone (as
discussed in <specref ref="presm_mrow"/>). This means that an <kw
role="element">mo</kw> element that is the sole argument of an <kw
role="element">mrow</kw> will determine its default <kw
role="attrib">form</kw> attribute based on that <kw
role="element">mrow</kw>'s position in a surrounding, perhaps inferred, <kw
role="element">mrow</kw> (if there is one), rather than based on its own
position in the <kw role="element">mrow</kw> in which it is the sole
argument.</p>
<p>Note that the above definition defines every
<kw role="element">mo</kw> element to be <quote>embellished</quote> – that is,
<quote>embellished operator</quote> can be considered (and implemented in
renderers) as a special class of MathML expressions, of which
<kw role="element">mo</kw> is a specific case.</p>
</div5>
<div5><head>Spacing around an operator</head>
<p>The amount of space added around an operator (or embellished operator),
when it occurs in an <kw role="element">mrow</kw>, can be directly
specified by the <kw role="attrib">lspace</kw> and <kw
role="attrib">rspace</kw> 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 &TeX;, 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.</p>
<p>Some renderers may choose to use no space around most operators
appearing within subscripts or superscripts, as is done in &TeX;.</p>
<p>Non-graphical renderers should treat spacing attributes, and other
rendering attributes described here, in analogous ways for their
rendering medium. For example, more space might translate into a
longer pause in an audio rendering.</p>
</div5>
</div4>
<div4><head>Stretching of operators, fences and accents</head>
<p>Four attributes govern whether and how an operator (perhaps embellished)
stretches so that it matches the size of other elements: <kw
role="attrib">stretchy</kw>, <kw role="attrib">symmetric</kw>, <kw
role="attrib">maxsize</kw>, and <kw role="attrib">minsize</kw>. If an
operator has the attribute <kw role="attrib">stretchy</kw>=<kw
role="attval">true</kw>, 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.</p>
<p>There is no provision in MathML for specifying in which direction
(horizontal or vertical) to stretch a specific character or operator;
rather, when <kw role="attrib">stretchy</kw>=<kw role="attval">true</kw> 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.)</p>
<p>The <kw role="attrib">minsize</kw> and <kw role="attrib">maxsize</kw>
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 <kw role="attrib">maxsize</kw>="3", then it
can grow to be no more than three times its normal (unstretched) size.</p>
<p>The <kw role="attrib">symmetric</kw> attribute governs whether the
height and
depth above and below the <intref ref="dt-axis">axis</intref> 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
<kw role="attrib">symmetric</kw>=<kw role="attval">false</kw>
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 <kw role="attrib">symmetric</kw> attribute only applies
to characters that stretch vertically (otherwise it is ignored).</p>
<p>If a stretchy <kw role="element">mo</kw> element is embellished (as defined
earlier in this section), the <kw role="element">mo</kw> 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:
<eg role='mathml'><![CDATA[
<mrow>
<munder>
<mo> ( </mo>
<mo> _ </mo>
</munder>
<mfrac>
<mi> a </mi>
<mi> b </mi>
</mfrac>
<mover>
<mo> ) </mo>
<mo> ‾ </mo>
</mover>
</mrow>
]]></eg>
</p>
<p>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 <kw role="element">mo</kw> element itself.</p>
<div5><head>Example of stretchy attributes</head>
<p>This shows one way to set the maximum size of a parenthesis so that
it does not grow, even though its default value is
<kw role="attrib">stretchy</kw>=<kw role="attval">true</kw>.
<eg role='mathml'><![CDATA[
<mrow>
<mo maxsize="1"> ( </mo>
<mfrac>
<mi> a </mi> <mi> b </mi>
</mfrac>
<mo maxsize="1"> ) </mo>
</mrow>
]]></eg>
</p>
<p>The above should render as
<graphic role="inline" source="image/f3001.gif" alt="(\frac{a}{b})"/>
as opposed to the default rendering
<graphic role="inline" source="image/f3002.gif" alt="\left(\frac{a}{b}\right)"/>.</p>
<p>Note that each parenthesis is sized independently; if only one of
them had <kw role="attrib">maxsize</kw>="1", they would render with different
sizes.</p>
</div5>
<div5><head>Vertical Stretching Rules</head>
<ulist>
<item><p>If a stretchy operator is a direct sub-expression of an <kw
role="element">mrow</kw> element, or is the sole direct sub-expression of an
<kw role="element">mtd</kw> element in some row of a table, then it should
stretch to cover the height and depth (above and below the <kw
role="attrib">axis</kw>) of the non-stretchy direct sub-expressions in the
<kw role="element">mrow</kw> element or table row, unless stretching is
constrained by <kw role="attrib">minsize</kw> or <kw
role="attrib">maxsize</kw> attributes.</p>
</item>
<item><p>In the case of an embellished stretchy operator, the preceding
rule applies to the stretchy operator at its core.</p>
</item>
<item><p>If <kw role="attrib">symmetric</kw>=<kw role="attval">true</kw>,
then the maximum of the height and depth is used to determine the size,
before application of the <kw role="attrib">minsize</kw> or <kw
role="attrib">maxsize</kw> attributes.</p>
</item>
<item><p>The preceding rules also apply in situations where the <kw
role="element">mrow</kw> element is inferred.</p>
</item>
</ulist>
<p>Most common opening and closing fences are defined in the operator
dictionary to stretch by default; and they stretch vertically. Also,
operators such as <kw role="entity">sum</kw>, <kw role="entity">int</kw>,
/, and vertical arrows stretch vertically by default.</p>
<p>In the case of a stretchy operator in a table cell (i.e. within an
<kw role="element">mtd</kw> element), the above rules assume each cell of
the table row containing the stretchy operator covers exactly one row.
(Equivalently, the value of the <kw role="attrib">rowspan</kw> 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
<specref ref="presm_mtdatts"/> for details about the <kw
role="attrib">rowspan</kw> attribute.
</p>
</div5>
<div5><head>Horizontal Stretching Rules</head>
<ulist>
<item><p>If a stretchy operator, or an embellished stretchy operator,
is a direct sub-expression of an <kw role="element">munder</kw>,
<kw role="element">mover</kw>, or <kw role="element">munderover</kw> element,
or if it is the sole direct sub-expression of an <kw
role="element">mtd</kw> element in some
column of a table (see <kw role="element">mtable</kw>), then it, or the <kw
role="element">mo</kw> 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.</p>
</item>
<item><p>If a stretchy operator is a direct sub-expression of an
<kw role="element">munder</kw>, <kw role="element">mover</kw>, or
<kw role="element">munderover</kw> element, or if it is the sole direct
sub-expression of an <kw role="element">mtd</kw> 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.</p>
</item>
<item><p>In the case of an embellished stretchy operator, the preceding
rule applies to the stretchy operator at its core.</p>
</item>
</ulist>
<p>By default, most horizontal arrows and some accents stretch
horizontally.</p>
<p>In the case of a stretchy operator in a table cell (i.e. within an
<kw role="element">mtd</kw> element), the above rules assume each cell of
the table column containing the stretchy operator covers exactly one
column. (Equivalently, the value of the <kw role="attrib">columnspan</kw>
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 <specref ref="presm_mtdatts" /> for details about the <kw
role="attrib">rowspan</kw> attribute. </p>
<p>The rules for horizontal stretching include <kw role="element">mtd</kw>
elements to allow arrows to stretch for use in commutative diagrams
laid out using <kw role="element">mtable</kw>. The rules for the horizontal
stretchiness include scripts to make examples such as the following
work:
<eg role='mathml'><![CDATA[
<mrow>
<mi> x </mi>
<munder>
<mo> → </mo>
<mtext> maps to </mtext>
</munder>
<mi> y </mi>
</mrow>
]]></eg>
</p>
<p>This displays as
<graphic role="inline" source="image/f3003.gif"
alt="x \widearrow{\mathrm{maps~to}} y"/>.</p>
</div5>
<div5><head>Rules Common to both Vertical and Horizontal Stretching</head>
<p>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.</p>
<p>If a stretchy operator is required to stretch, but all other expressions
in the containing element (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 <kw role="attrib">minsize</kw> or <kw
role="attrib">maxsize</kw> prevents this then that (min or max) size is
used.</p>
<p>For example, in an <kw role="element">mrow</kw> 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.</p>
</div5>
</div4>
<div4><head>Other attributes of <kw role="element">mo</kw></head>
<p>The <kw role="attrib">largeop</kw> attribute specifies whether the
operator should be drawn larger than normal if <kw
role="attrib">displaystyle</kw>=<kw role="attval">true</kw> in the current
rendering environment. This roughly corresponds to &TeX;'s
<kw>\displaystyle</kw> style setting. MathML uses two attributes, <kw
role="attrib">displaystyle</kw> and <kw role="attrib">scriptlevel</kw>, to
control orthogonal presentation features that &TeX; encodes into one
<quote>style</quote> attribute with values <kw>\displaystyle</kw>,
<kw>\textstyle</kw>, <kw>\scriptstyle</kw>, and
<kw>\scriptscriptstyle</kw>. These attributes are discussed further in
<specref ref="presm_mstyle"/> describing the <kw role="element">mstyle</kw> element.
Note that these attributes can be specified directly on an <kw
role="element">mstyle</kw> element's start tag, but not on most other
elements. Examples of large operators include <kw role="entity">int</kw>
and <kw role="entity">prod</kw>.</p>
<p>The <kw role="attrib">movablelimits</kw> attribute specifies whether
underscripts and overscripts attached to this <kw role="element">mo</kw>
element should be drawn as subscripts and superscripts when <kw
role="attrib">displaystyle</kw>=<kw role="attval">false</kw>. <kw
role="attrib">movablelimits</kw>=<kw role="attval">false</kw> means that
underscripts and overscripts should never be drawn as subscripts and
superscripts. In general, <kw role="attrib">displaystyle</kw> is <kw
role="attval">true</kw> for displayed mathematics and <kw
role="attval">false</kw> for inline mathematics. Also, <kw
role="attrib">displaystyle</kw> is <kw role="attval">false</kw> by default
within tables, scripts and fractions, and a few other exceptional
situations detailed in <specref ref="presm_mstyle"/>. Thus, operators with
<kw role="attrib">movablelimits</kw>=<kw role="attval">true</kw> 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 <kw
role="attrib">movablelimits</kw>=<kw role="attval">true</kw> are <kw
role="element">sum</kw>, <kw role="element">prod</kw>, and <kw
role="element">lim</kw>.</p>
<p>The <kw role="attrib">accent</kw> attribute determines whether this
operator should be treated by default as an accent (diacritical mark) when
used as an underscript or overscript; see <kw role="element">munder</kw>,
<kw role="element">mover</kw>, and <kw role="element">munderover</kw>
(<specref ref="presm_munder"/>, <specref ref="presm_mover"/> and <specref
ref="presm_munderover"/>).</p>
<p>The <kw role="attrib">separator</kw> 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.</p>
<p>The <kw role="attrib">fence</kw> 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.</p>
</div4>
</div3>
<div3 id="presm_mtext"><head>Text (<kw role="element">mtext</kw>)</head>
<div4><head>Description</head>
<p>An <kw role="element">mtext</kw> element is used to represent
arbitrary text that should be rendered as itself. In general, the
<kw role="element">mtext</kw> element is intended to denote commentary
text.</p>
<p>Note that some text with a clearly defined notational role might be
more appropriately marked up using <kw role="element">mi</kw> or
<kw role="element">mo</kw>; this is discussed further below.</p>
<p>An <kw role="element">mtext</kw> element can be used to contain
<quote>renderable whitespace</quote>, 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
<specref ref="fund_collapse"/>. Whitespace that is intended to be rendered
as part of an element's content must be represented by entity references
or <kw role="element">mspace</kw> elements
(unless it consists only of single blanks between non-whitespace
characters).</p>
<p>Renderable whitespace can have a positive or negative width, as in <kw
role="entity">ThinSpace</kw> and <kw role="entity">NegativeThinSpace</kw>,
or zero width, as in <kw role="entity">ZeroWidthSpace</kw>. The complete
list of such characters is given in <specref ref="chars"/>. Note that there
is no formal distinction in MathML between renderable whitespace characters
and any other class of characters, in <kw role="element">mtext</kw> or in
any other element.</p>
<p>Renderable whitespace can also include
characters that affect alignment or linebreaking. Some of these
characters are:
<table border="1">
<thead>
<tr>
<td>Entity name</td>
<td>Purpose (rough description)</td>
</tr>
</thead>
<tbody>
<tr>
<td>
</td>
<td>start a new line and do not indent</td>
</tr>
<tr>
<td>&IndentingNewLine;</td>
<td>start a new line and do indent</td>
</tr>
<tr>
<td>⁠</td>
<td>do not allow a linebreak here</td>
</tr>
<tr>
<td>&GoodBreak;</td>
<td>if a linebreak is needed on the line, here is a good spot</td>
</tr>
<tr>
<td>&BadBreak;</td>
<td>if a linebreak is needed on the line, try to avoid breaking here</td>
</tr>
</tbody>
</table>
</p>
<p>For the complete list of MathML entities, consult <specref ref="chars"/>.</p>
</div4>
<div4><head>Attributes</head>
<p><kw role="element">mtext</kw> elements accept the attributes listed in
<specref ref="presm_commatt"/>.</p>
<p>See also the warnings about the legal grouping of <quote>space-like
elements</quote> in <specref ref="presm_mspace"/>, and about the use of
such elements for <quote>tweaking</quote> or conveying meaning in <specref
ref="presm_mpadded"/>.</p>
</div4>
<div4><head>Examples</head>
<eg role='mathml'><![CDATA[
<mtext> Theorem 1: </mtext>
<mtext>   </mtext>
<mtext>      </mtext>
<mtext> /* a comment */ </mtext>
]]></eg>
</div4>
<div4 id="presm_mixtextmath"><head>Mixing text and mathematics</head>
<p>In some cases, text embedded in mathematics could be more appropriately
represented using <kw role="element">mo</kw> or <kw role="element">mi</kw> elements.
For example, the expression `there exists
<graphic role="inline" source="image/f3004.gif" alt="\delta>0"/>
such that <mi>f</mi>(<mi>x</mi>) <1' is equivalent to
<graphic role="inline" source="image/f3005.gif"
alt="\exists \delta>0 \backepsilon f(x)<1"/>
and could be represented as:
<eg role='mathml'><![CDATA[
<mrow>
<mo> there exists </mo>
<mrow>
<mrow>
<mi> δ </mi>
<mo> > </mo>
<mn> 0 </mn>
</mrow>
<mo> such that </mo>
<mrow>
<mrow>
<mi> f </mi>
<mo> ⁡ </mo>
<mrow>
<mo> ( </mo>
<mi> x </mi>
<mo> ) </mo>
</mrow>
</mrow>
<mo> < </mo>
<mn> 1 </mn>
</mrow>
</mrow>
</mrow>
]]></eg>
</p>
<p>An example involving an <kw role="element">mi</kw> element is:
<mi>x</mi>+<mi>x</mi><sup>2</sup>+···+<mi>x</mi><sup><mi>n</mi></sup>.
In this example, ellipsis should be represented using an <kw
role="element">mi</kw> element, since it takes the place of a term in the
sum; (see <specref ref="presm_mi"/>).</p>
<p>On the other hand, expository text within MathML is best
represented with an <kw role="element">mtext</kw> element. An example
of this is: <eg role='text'> Theorem 1: if <mi>x</mi> > 1, then
<mi>x</mi><sup>2</sup> > <mi>x</mi>. </eg> However, when MathML is
embedded in HTML, or another document markup language, 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.</p>
<p>Another factor to consider in deciding how to mark up text is the
effect on rendering. Text enclosed in an <kw role="element">mo</kw>
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
<quote>unrecognized operator</quote>, which may or may not be better than the
format and spacing for <quote>text</quote> obtained by using an
<kw role="element">mtext</kw> element. An ellipsis entity in an
<kw role="element">mi</kw> element is apt to be spaced more appropriately
for taking the place of a term within a series than if it appeared in
an <kw role="element">mtext</kw> element.</p>
</div4>
</div3>
<div3 id="presm_mspace"><head>Space (<kw role="element">mspace</kw>)</head>
<div4><head>Description</head>
<p>An <kw role="element">mspace</kw> empty element represents a blank
space of any desired size, as set by its attributes. It can also be
used to make linebreaking suggestions to a visual renderer.
Note that the default values for attributes have been chosen so that
they typically will have no effect on rendering. Thus, the <kw
role="element">mspace</kw> element is generally used with one
or more attribute values explicitly specified.
</p>
</div4>
<div4><head>Attributes</head>
<p>In addition to the attributes listed below,
<kw role="element">mspace</kw> permits
<kw role="attrib">id</kw>,
<kw role="attrib">xref</kw>, <kw role="attrib">class</kw> and
<kw role="attrib">style</kw> attributes,
as described in <specref ref="fund_globatt"/>.</p>
<table border="1">
<thead>
<tr>
<td>Name</td>
<td>values</td>
<td>default</td>
</tr>
</thead>
<tbody>
<tr>
<td>width</td>
<td>number h-unit | namedspace</td>
<td>0em</td>
<!-- em is shown in the table to indicate that it is a typical unit -->
</tr>
<tr>
<td>height</td>
<td>number v-unit</td>
<td>0ex</td>
<!-- ex is shown in the table to indicate that it is a typical unit -->
</tr>
<tr>
<td>depth</td>
<td>number v-unit</td>
<td>0ex</td>
</tr>
<tr>
<td>linebreak</td>
<td>auto | newline | indentingnewline | nobreak | goodbreak | badbreak</td>
<td>auto</td>
</tr>
</tbody>
</table>
<p><kw role="attval">h-unit</kw> and <kw role="attval">v-unit</kw>
represent units of horizontal or vertical length, respectively (see
<specref ref="fund_units"/>).</p>
<p>The <kw role="attrib">linebreak</kw> attribute is used to give a
linebreaking hint to a visual renderer. The default value is <kw
role="attval">auto</kw>, which indicates that a renderer should use
whatever default linebreaking algorithm it would normally use. The
meaning of the other possible values for the <kw
role="attrib">linebreak</kw> attribute are described above in the
discussion on renderable whitespace in the <kw
role="element">mtext</kw> element. See <specref ref="presm_mtext"/>
for details.</p>
<p>In the case when both dimensional attributes and a linebreaking
attribute are set, the linebreaking attribute is ignored.</p>
<p>Note the warning about the legal grouping of <quote>space-like elements</quote>
given below, and the warning about the use of such elements for
<quote>tweaking</quote> or conveying meaning in <specref ref="presm_mpadded"/>. See also the other
elements that can render as whitespace, namely
<kw role="element">mtext</kw>, <kw role="element">mphantom</kw>, and
<kw role="element">maligngroup</kw>.</p>
</div4>
<div4><head>Definition of space-like elements</head>
<p>A number of MathML presentation elements are <quote>space-like</quote> 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
<kw role="element">mo</kw> given in <specref ref="presm_mo"/>.
The following MathML elements are defined to be <quote>space-like</quote>:
<ulist>
<item><p>an <kw role="element">mtext</kw>, <kw role="element">mspace</kw>,
<kw role="element">maligngroup</kw>, or <kw role="element">malignmark</kw>
element;</p> </item>
<item><p>an <kw role="element">mstyle</kw>, <kw role="element">mphantom</kw>, or
<kw role="element">mpadded</kw> element, all of whose direct sub-expressions
are space-like;</p> </item>
<item><p>an <kw role="element">maction</kw> element whose selected
sub-expression exists and is space-like;</p> </item>
<item><p>an <kw role="element">mrow</kw> all of whose direct
sub-expressions are space-like.</p>
</item>
<!-- note: not an embellished space-like thing, though this would be arguable. -->
</ulist>
</p>
<p>Note that an <kw role="element">mphantom</kw> is <emph>not</emph>
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
<kw role="element">mphantom</kw> element is primarily intended as an aid
in aligning expressions, operators adjacent to an
<kw role="element">mphantom</kw> should behave as if they were adjacent
to the <emph>contents</emph> of the <kw role="element">mphantom</kw>,
rather than to an equivalently sized area of whitespace.</p>
</div4>
<div4><head>Legal grouping of space-like elements</head>
<p>Authors who insert space-like elements or
<kw role="element">mphantom</kw> elements into an existing MathML
expression should note that such elements <emph>are</emph> counted as
arguments, in elements that require a specific number of arguments,
or that interpret different argument positions differently.</p>
<p>Therefore, space-like elements inserted into such a MathML element
should be grouped with a neighboring argument of that element by
introducing an <kw role="element">mrow</kw> for that purpose. For example,
to allow for vertical alignment on the right edge of the base of a
superscript, the expression
<eg role="mathml-error"><![CDATA[
<msup>
<mi> x </mi>
<malignmark edge="right"/>
<mn> 2 </mn>
</msup>
]]></eg>
is illegal, because <kw role="element">msup</kw> must have exactly 2 arguments;
the correct expression would be:
<eg role='mathml'><![CDATA[
<msup>
<mrow>
<mi> x </mi>
<malignmark edge="right"/>
</mrow>
<mn> 2 </mn>
</msup>
]]></eg>
</p>
<p>See also the warning about <quote>tweaking</quote> in
<specref ref="presm_mpadded"/>.</p>
</div4>
</div3>
<div3 id="presm_ms"><head>String Literal (<kw role="element">ms</kw>)</head>
<div4><head>Description</head>
<p>The <kw role="element">ms</kw> element is used to represent
<quote>string literals</quote> in expressions meant to be interpreted by
computer algebra systems or other systems containing <quote>programming
languages</quote>. By default, string literals are displayed surrounded by
double quotes. As explained in <specref ref="presm_mtext"/>, ordinary text
embedded in a mathematical expression should be marked up with <kw
role="element">mtext</kw>, or in some cases <kw role="element">mo</kw> or
<kw role="element">mi</kw>, but never with <kw role="element">ms</kw>.</p>
<p>Note that the string literals encoded by <kw role="element">ms</kw>
are <quote>Unicode strings</quote> rather than <quote>ASCII
strings</quote>. In practice, non-ASCII characters will typically be
represented by entity references. For example,
<code><ms>&</ms></code> represents a
string literal containing a single character, <code>&</code>, and
<code><ms>&amp;</ms></code> represents a
string literal containing 5 characters, the first one of which is
<code>&</code>.</p>
<p>Like all token elements, <kw role="element">ms</kw> <emph>does</emph> trim and
collapse whitespace in its content according to the rules of
<specref ref="fund_collapse"/>, so whitespace intended to remain in
the content should be encoded as described in that section.</p>
</div4>
<div4><head>Attributes</head>
<p><kw role="element">ms</kw> elements accept the attributes listed in
<specref ref="presm_commatt"/>, and additionally: </p>
<table border="1">
<thead>
<tr>
<td>Name</td>
<td>values</td>
<td>default</td>
</tr>
</thead>
<tbody>
<tr>
<td>lquote</td>
<td>string</td>
<td><kw role="entity">quot</kw></td>
</tr>
<tr>
<td>rquote</td>
<td>string</td>
<td><kw role="entity">quot</kw></td>
</tr>
</tbody>
</table>
<p>In visual renderers, the content of an <kw role="element">ms</kw>
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 <kw role="entity">quot</kw>. However,
these characters can be changed with the <kw role="attrib">lquote</kw> and
<kw role="attrib">rquote</kw> attributes respectively.</p>
<p>The content of <kw role="element">ms</kw> elements should be rendered
with visible <quote>escaping</quote> of certain characters in the content,
including at least <quote>double quote</quote> itself, and preferably whitespace
other than individual space characters. 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, <code><ms>double quote is
"</ms></code> might be rendered as "double quote is
\"".</p>
</div4>
</div3>
<div3 id="presm_mglyph"><head>Adding new character glyphs to MathML
(<kw role="element">mglyph</kw>)</head>
<div4><head>Description</head>
<p>Unicode defines a large number of characters used in mathematics,
and in most 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 meantime, a mechanism is necessary for
accessing glyphs from non-standard fonts representing these characters.</p>
<p>The <kw role="element">mglyph</kw> element is the means by which
users can directly access glyphs for characters that are not defined
by Unicode, or not known to the renderer. Similarly, the <kw
role="element">mglyph</kw> 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.</p>
<p>The <kw role="element">mglyph</kw> element names a specific
character glyph, and is valid inside any MathML leaf content listed in
<specref ref="presm_summary"/> (<kw role="element">mi</kw>, etc.) or
<specref ref="contm_container"/> (<kw role="element">ci</kw>, etc.)
unless otherwise restricted by an attribute (e.g. <kw
role="attrib">base</kw>=2 to <kw role="starttag">cn</kw>). 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.</p>
</div4>
<div4><head>Attributes</head>
<p><kw role="element">mglyph</kw> elements accept the attributes listed in
<specref ref="presm_commatt"/>, and the additional attributes listed here.</p>
<table border="1">
<thead>
<tr>
<td>Name</td>
<td>values</td>
<td>default</td>
</tr>
</thead>
<tbody>
<tr>
<td>alt</td>
<td>string</td>
<td>required</td>
</tr>
<tr>
<td>fontfamily</td>
<td>string | css-fontfamily</td>
<td>required</td>
</tr>
<tr>
<td>index</td>
<td>integer</td>
<td>required</td>
</tr>
</tbody>
</table>
<p>The <kw role="attrib">alt</kw> 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 <kw
role="attrib">fontfamily</kw> and <kw role="attrib">index</kw>
uniquely identify the <kw role="element">mglyph</kw>; two <kw
role="element">mglyph</kw>s with the same values for <kw
role="attrib">fontfamily</kw> and <kw role="attrib">index</kw> should
be considered identical by applications that must determine whether
two characters/glyphs are identical. The <kw role="attrib">alt</kw>
attribute should not be part of the identity test.</p>
<p>The <kw role="attrib">fontfamily</kw> and <kw
role="attrib">index</kw> attributes name a font and position within
that font. All font properties apart from <kw
role="attrib">fontfamily</kw> 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.</p>
<p>Authors should be aware that rendering requires the fonts
referenced by <kw role="element">mglyph</kw>, 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 <kw role="element">mglyph</kw> only when
absolutely necessary, and not for stylistic purposes.</p>
</div4>
<div4><head>Example</head>
<p>The following example illustrates how a researcher might use the <kw
role="element">mglyph</kw> construct with an experimental font to work
with braid group notation.
<eg role='mathml'><![CDATA[
<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>
</mrow>
]]></eg>
This might render as:
<graphic role="display" source="image/f3006.gif" alt="\includegraphics{braids}"/>
</p>
</div4>
</div3>
</div2>
<div2 id="presm_genlayout"><head>General Layout Schemata</head>
<p>Besides tokens there are several families of MathML presentation
elements. One family of elements deals with various
<quote>scripting</quote> 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.</p>
<div3 id="presm_mrow"><head>Horizontally Group Sub-Expressions
(<kw role="element">mrow</kw>)</head>
<div4><head>Description</head>
<p>An <kw role="element">mrow</kw> element is used to group together any
number of sub-expressions, usually consisting of one or more <kw
role="element">mo</kw> elements acting as <quote>operators</quote> on one
or more other expressions that are their <quote>operands</quote>.</p>
<p>Several elements automatically treat their arguments as if they were
contained in an <kw role="element">mrow</kw> element. See the discussion of
inferred <kw role="element">mrow</kw>s in <specref
ref="presm_reqarg"/>. See also <kw role="element">mfenced</kw> (<specref
ref="presm_mfenced"/>), which can effectively form an <kw
role="element">mrow</kw> containing its arguments separated by commas.</p>
</div4>
<div4><head>Attributes</head>
<p>This element only permits <kw role="attrib">id</kw>,
<kw role="attrib">xref</kw>, <kw role="attrib">class</kw> and
<kw role="attrib">style</kw> attributes,
as described in <specref ref="fund_globatt"/>.</p>
<p><kw role="element">mrow</kw> 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 <specref ref="presm_mo"/> of suggested rendering
rules for <kw role="element">mo</kw> elements assumes that all horizontal
spacing between operators and their operands is added by the rendering
of <kw role="element">mo</kw> elements (or, more generally, embellished
operators), not by the rendering of the <kw role="element">mrow</kw>s
they are contained in.</p>
<p>MathML is designed to allow renderers to automatically
<emph>linebreak</emph> 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.</p>
<p>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
<quote>good</quote> points for insertion of linebreaks between successive
arguments of <kw role="element">mrow</kw> elements.</p>
<p>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 <specref ref="presm_mo"/>), or for providing hints related to
linebreaking when necessary (see <specref ref="presm_mtext"/>), and the ability to
use nested <kw role="element">mrow</kw>s to describe sub-expression
structure (see below).</p>
<div5><head><kw role="element">mrow</kw> of one argument</head>
<p>MathML renderers are required to treat an <kw role="element">mrow</kw>
element containing exactly one argument as equivalent in all ways to
the single argument occurring alone, provided there are no attributes
on the <kw role="element">mrow</kw> element's start tag. If there are
attributes on the <kw role="element">mrow</kw> element's start 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 <kw role="attrib">form</kw>
attribute of an <kw role="element">mo</kw> element;
see <specref ref="presm_mo"/> and <specref
ref="presm_mspace"/>. See also the discussion of equivalence of MathML
expressions in <specref ref="interf"/>.</p>
</div5>
</div4>
<div4><head>Proper grouping of sub-expressions using <kw role="element">mrow</kw></head>
<p>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 <quote>syntax tree</quote> of the
expression. Specifically, operators and their mathematical arguments should
occur in a single <kw role="element">mrow</kw>; more than one operator
should occur directly in one <kw role="element">mrow</kw> 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
<code>+</code> and <code>-</code>. A precise rule is given below.</p>
<p>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.</p>
<p>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
<kw role="element">mrow</kw> is allowed in MathML syntax; that is,
renderers should not assume the rules for proper grouping will be
followed.</p>
<div5><head>Precise rule for proper grouping</head>
<p>A precise rule for when and how to nest sub-expressions using
<kw role="element">mrow</kw> is especially desirable when generating
MathML automatically by conversion from other formats for displayed
mathematics, such as &TeX;, which don't always specify how sub-expressions
nest. When a precise rule for grouping is desired, the following rule
should be used:</p>
<p>Two adjacent operators (i.e. <kw role="element">mo</kw> elements,
possibly embellished), possibly separated by operands (i.e. anything
other than operators), should occur in the same
<kw role="element">mrow</kw> 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 <specref ref="oper-dict"/>.
In all other cases, nested <kw role="element">mrow</kw>s should be used.</p>
<p>When forming a nested <kw role="element">mrow</kw> (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 (<specref ref="oper-dict"/>) can be assumed to have
a higher precedence for this purpose.</p>
<p>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.</p>
<p>(Some of the terminology used in stating the above rule in defined
in <specref ref="presm_mo"/>.)</p>
</div5>
</div4>
<div4><head>Examples</head>
<p>As an example, 2<mi>x</mi>+<mi>y</mi>-<mi>z</mi>
should be written as:
<eg role="mathml"><![CDATA[
<mrow>
<mrow>
<mn> 2 </mn>
<mo> ⁢ </mo>
<mi> x </mi>
</mrow>
<mo> + </mo>
<mi> y </mi>
<mo> - </mo>
<mi> z </mi>
</mrow>
]]></eg>
</p>
<p>The proper encoding of (<mi>x</mi>, <mi>y</mi>) furnishes a less obvious
example of nesting <kw role="element">mrow</kw>s:
<eg role='mathml'><![CDATA[
<mrow>
<mo> ( </mo>
<mrow>
<mi> x </mi>
<mo> , </mo>
<mi> y </mi>
</mrow>
<mo> ) </mo>
</mrow>
]]></eg>
</p>
<p>In this case, a nested <kw role="element">mrow</kw> is required inside
the parentheses, since parentheses and commas, thought of as fence and
separator <quote>operators</quote>, do not act together on their arguments.</p>
</div4>
</div3>
<div3 id="presm_mfrac"><head>Fractions (<kw role="element">mfrac</kw>)</head>
<div4><head>Description</head>
<p>The <kw role="element">mfrac</kw> 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 <kw role="element">mfrac</kw> is
<eg>
<mfrac> <emph>numerator</emph> <emph>denominator</emph> </mfrac>
</eg></p>
</div4>
<div4><head>Attributes of <kw role="element">mfrac</kw></head>
<p>In addition to the attributes listed below, this element permits
<kw role="attrib">id</kw>,
<kw role="attrib">xref</kw>, <kw role="attrib">class</kw> and
<kw role="attrib">style</kw> attributes,
as described in <specref ref="fund_globatt"/>.</p>
<table border="1">
<thead>
<tr>
<td>Name</td>
<td>values</td>
<td>default</td>
</tr>
</thead>
<tbody>
<tr>
<td>linethickness</td>
<td>number [ v-unit ] | thin | medium | thick</td>
<td>1 (rule thickness)</td>
</tr>
<tr>
<td>numalign</td>
<td>left | center | right</td>
<td>center</td>
</tr>
<tr>
<td>denomalign</td>
<td>left | center | right</td>
<td>center</td>
</tr>
<tr>
<td>bevelled</td>
<td>true | false</td>
<td>false</td>
</tr>
</tbody>
</table>
<p>The <kw role="attrib">linethickness</kw> attribute indicates the thickness of
the horizontal <quote>fraction bar</quote>, or <quote>rule</quote>, typically used to render
fractions. A fraction with <kw role="attrib">linethickness</kw>="0" renders
without the bar, and might be used within binomial coefficients. A
<kw role="attrib">linethickness</kw> greater than one might be used with nested
fractions. These cases are shown below:
<graphic source="image/f3007.gif"
alt="{a \choose b} \quad {a \over b} \above1pt {c \over d}"/></p>
<p>In general, the value of <kw role="attrib">linethickness</kw> 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 <specref ref="fund_units"/>), or one of the keywords
<code>medium</code> (same as 1), <code>thin</code> (thinner than 1,
otherwise up to the renderer), or <code>thick</code> (thicker than 1,
otherwise up to the renderer).</p>
<p>The <kw role="attrib">numalign</kw> and
<kw role="attrib">denomalign</kw> 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.</p>
<p>The <kw role="attrib">bevelled</kw> 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 latter form
corresponds to the attribute value being <kw role="attval">true</kw>
and provides for a more compact form for simple numerator and
denominators. An example illustrating the bevelled form is show below:
<graphic source="image/f3008.gif"
alt="\frac{1}{x^3 + \frac{x}{3}} = \raisebox{1ex}{$1$}\!
\left/ \!\raisebox{-1ex}{$x^3+\frac{x}{3}$} \right."/>
</p>
<p>The <kw role="element">mfrac</kw> element sets <kw
role="attrib">displaystyle</kw> to <kw role="attval">false</kw>, or if it
was already false increments <kw role="attrib">scriptlevel</kw> by 1,
within <emph>numerator</emph> and <emph>denominator</emph>. These
attributes are inherited by every element from its rendering environment,
but can be set explicitly only on the <kw role="element">mstyle</kw>
element. (See <specref ref="presm_mstyle"/>.) </p>
</div4>
<div4><head>Examples</head>
<p>The examples shown above can be represented in MathML as:
<eg role='mathml'><![CDATA[
<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>
]]></eg>
<eg role='mathml'><![CDATA[
<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 bevelled="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>
]]></eg>
</p>
<p>A more generic example is:
<eg role='mathml'><![CDATA[
<mfrac>
<mrow>
<mn> 1 </mn>
<mo> + </mo>
<msqrt>
<mn> 5 </mn>
</msqrt>
</mrow>
<mn> 2 </mn>
</mfrac>
]]></eg>
</p>
</div4>
</div3>
<div3 id="presm_mroot"><head>Radicals (<kw role="element">msqrt</kw>, <kw role="element">mroot</kw>)</head>
<div4><head>Description</head>
<p>These elements construct radicals. The <kw role="element">msqrt</kw> element is
used for square roots, while the <kw role="element">mroot</kw> element is used
to draw radicals with indices, e.g. a cube root. The syntax for these
elements is:
<eg>
<msqrt> <emph>base</emph> </msqrt>
<mroot> <emph>base</emph> <emph>index</emph> </mroot>
</eg>
</p>
<p>The <kw role="element">mroot</kw> element requires exactly 2 arguments.
However, <kw role="element">msqrt</kw> accepts any number of arguments; if
this number is not 1, its contents are treated as a single <quote>inferred
<kw role="element">mrow</kw></quote> containing its arguments, as described in
<specref ref="presm_reqarg"/>.</p>
</div4>
<div4><head>Attributes</head>
<p>This element only permits <kw role="attrib">id</kw>,
<kw role="attrib">xref</kw>, <kw role="attrib">class</kw> and
<kw role="attrib">style</kw> attributes,
as described in <specref ref="fund_globatt"/>.</p>
<p>The <kw role="element">mroot</kw> element increments <kw
role="attrib">scriptlevel</kw> by 2, and sets <kw
role="attrib">displaystyle</kw> to <kw role="attval">false</kw>, within
<emph>index</emph>, but leaves both attributes unchanged within
<emph>base</emph>. The <kw role="element">msqrt</kw> 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 <kw role="element">mstyle</kw>. (See <specref
ref="presm_mstyle"/>.)</p>
</div4>
</div3>
<div3 id="presm_mstyle"><head>Style Change (<kw role="element">mstyle</kw>)</head>
<div4><head>Description</head>
<p>The <kw role="element">mstyle</kw> element is used to make style
changes that affect the rendering of its
contents. <kw role="element">mstyle</kw> 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 <kw role="element">mstyle</kw> element. In addition
<kw role="element">mstyle</kw> can also be given certain special
attributes listed below.</p>
<p>The <kw role="element">mstyle</kw> element accepts any number of
arguments. If this number is not 1, its contents are treated as a single
<quote>inferred <kw role="element">mrow</kw></quote> formed from all its
arguments, as described in <specref ref="presm_reqarg"/>.</p>
<p>Loosely speaking, the effect of the <kw role="element">mstyle</kw> 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:
<ulist>
<item><p>Some attributes, such as <kw role="attrib">displaystyle</kw> or
<kw role="attrib">scriptlevel</kw> (explained below), are inherited
from the surrounding context when they are not explicitly set. Specifying
such an attribute on an <kw role="element">mstyle</kw> 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 <kw role="attrib">scriptlevel</kw>), the new (overriding)
value will be passed on to that element's children, and then to their
children, etc, until it is again overridden.</p>
</item>
<item><p>Other attributes, such as <kw role="attrib">linethickness</kw> on
<kw role="element">mfrac</kw>, have default values that are not normally
inherited. That is, if the <kw role="attrib">linethickness</kw> attribute
is not set on the start tag of an <kw role="element">mfrac</kw> element,
it will normally use the default value of <kw role="attval">1</kw>, even if it was
contained in a larger <kw role="element">mfrac</kw> element that set this
attribute to a different value. For attributes like this, specifying a
value with an <kw role="element">mstyle</kw> 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 <kw
role="element">mstyle</kw> 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.</p>
</item>
<item><p>Another group of attributes, such as <kw
role="attrib">stretchy</kw> and <kw role="attrib">form</kw>, are
computed from operator dictionary information, position in the
enclosing <kw role="element">mrow</kw>, and other similar data. For
these attributes, a value specified by an enclosing <kw
role="element">mstyle</kw> overrides the value that would normally be
computed.</p>
</item>
</ulist>
</p>
<p>Note that attribute values inherited from an
<kw role="element">mstyle</kw> in any manner affect a given element
in the <kw role="element">mstyle</kw>'s content only if that attribute is
not given a value in that element's start tag. On any element for
which the attribute is set explicitly, the value specified on the
start tag overrides the inherited value. The only exception to this
rule is when the value given on the start tag is documented as
specifying an incremental change to the value inherited from that
element's context or rendering environment.</p>
<p>Note also that the difference between inherited and non-inherited
attributes set by <kw role="element">mstyle</kw>, explained above, only
matters when the attribute is set on some element within the
<kw role="element">mstyle</kw>'s contents that has children also
setting it. Thus it never matters for attributes, such as
<kw role="attrib">color</kw>, which can only be set on token elements (or on
<kw role="element">mstyle</kw> itself).</p>
<p>There is one exceptional element, <kw role="element">mpadded</kw>,
whose attributes cannot be set with <kw role="element">mstyle</kw>.
The <kw role="element">mpadded</kw> element shares several attribute
names with the <kw role="element">mspace</kw> and <kw
role="element">mo</kw> elements. Thus, when the attributes <kw
role="attrib">width</kw>, <kw role="attrib">height</kw> and <kw
role="attrib">depth</kw> are specified on an <kw
role="element">mstyle</kw> element, they apply only to the <kw
role="element">mspace</kw> element, and not the corresponding
attributes of <kw role="element">mpadded</kw>. Similarly, when <kw
role="attrib">lspace</kw> is set with <kw role="element">mstyle</kw>,
it applies only to the <kw role="element">mo</kw> element.</p> </div4>
<div4><head>Attributes</head>
<p>As stated above, <kw role="element">mstyle</kw> 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 <kw role="element">mstyle</kw> element.</p>
<p>This element also accepts
<kw role="attrib">id</kw>,
<kw role="attrib">xref</kw>, <kw role="attrib">class</kw> and
<kw role="attrib">style</kw> attributes,
as described in <specref ref="fund_globatt"/>.</p>
<p>Additionally, <kw role="element">mstyle</kw> can be given the following special
attributes that are implicitly inherited by every MathML element as
part of its rendering environment:
<table border="1">
<thead>
<tr>
<td>Name</td>
<td>values</td>
<td>default</td>
</tr>
</thead>
<tbody>
<tr>
<td>scriptlevel</td>
<td>['+' | '-'] unsigned-integer</td>
<td>inherited</td>
</tr>
<tr>
<td>displaystyle</td>
<td>true | false</td>
<td>inherited</td>
</tr>
<tr>
<td>scriptsizemultiplier</td>
<td>number</td>
<td>0.71</td>
</tr>
<tr>
<td>scriptminsize</td>
<td>number v-unit</td>
<td>8pt</td>
</tr>
<tr>
<td>color</td>
<td>#rgb | #rrggbb | html-color-name</td>
<td>inherited</td>
</tr>
<tr>
<td>background</td>
<td>#rgb | #rrggbb | transparent | html-color-name</td>
<td>transparent</td>
</tr>
<tr>
<td>veryverythinmathspace</td>
<td>number h-unit</td>
<td>0.0555556em</td>
</tr>
<tr>
<td>verythinmathspace</td>
<td>number h-unit</td>
<td>0.111111em</td>
</tr>
<tr>
<td>thinmathspace</td>
<td>number h-unit</td>
<td>0.166667em</td>
</tr>
<tr>
<td>mediummathspace</td>
<td>number h-unit</td>
<td>0.222222em</td>
</tr>
<tr>
<td>thickmathspace</td>
<td>number h-unit</td>
<td>0.277778em</td>
</tr>
<tr>
<td>verythickmathspace</td>
<td>number h-unit</td>
<td>0.333333em</td>
</tr>
<tr>
<td>veryverythickmathspace</td>
<td>number h-unit</td>
<td>0.388889em</td>
</tr>
</tbody>
</table>
</p>
<div5><head><kw role="attrib">scriptlevel</kw> and <kw role="attrib">displaystyle</kw></head>
<p>MathML uses two attributes, <kw role="attrib">displaystyle</kw> and
<kw role="attrib">scriptlevel</kw>, to control orthogonal presentation features
that &TeX; encodes into one <kw role="attrib">style</kw> attribute with values
\displaystyle, \textstyle, \scriptstyle, and \scriptscriptstyle. The
corresponding values of <kw role="attrib">displaystyle</kw> and
<kw role="attrib">scriptlevel</kw> for those &TeX; styles would be <kw role="attval">true</kw> and
<kw role="attval">0</kw>, <kw role="attval">false</kw> and
<kw role="attval">0</kw>, <kw role="attval">false</kw> and
<kw role="attval">1</kw>, and <kw role="attval">false</kw> and <kw role="attval">2</kw>,
respectively.</p>
<p>The main effect of the <kw role="attrib">displaystyle</kw> attribute is that
it determines the effect of other attributes such as the
<kw role="attrib">largeop</kw> and <kw role="attrib">movablescripts</kw> attributes of
<kw role="element">mo</kw>. The main effect of the
<kw role="attrib">scriptlevel</kw> attribute is to control the font
size. Typically, the higher the <kw role="attrib">scriptlevel</kw>, 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 <kw role="attrib">displaystyle</kw>=<kw role="attval">false</kw> in a more
vertically compressed manner.</p>
<p>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.</p>
<p>For an instance of MathML embedded in a textual data format (such
as HTML) in <quote>display</quote> mode, i.e. in place of a paragraph,
<kw role="attrib">displaystyle</kw> = <kw role="attval">true</kw> and
<kw role="attrib">scriptlevel</kw> = <kw role="attval">0</kw> for the
outermost expression of the embedded MathML; if the
MathML is embedded in <quote>inline</quote> mode, i.e. in place of a character,
<kw role="attrib">displaystyle</kw> = <kw role="attval">false</kw> and
<kw role="attrib">scriptlevel</kw> = <kw role="attval">0</kw> for
the outermost expression. See <specref ref="interf"/> for further
discussion of the distinction between <quote>display</quote> and <quote>inline</quote>
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
<kw role="attrib">displaystyle</kw> = "<kw role="attval">true</kw>" and
<kw role="attrib">scriptlevel</kw> = "<kw role="attval">0</kw>".</p>
<p>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 <kw role="attrib">displaystyle</kw> to <kw role="attval">false</kw>, and in some cases increase
<kw role="attrib">scriptlevel</kw>, for those arguments. The new values are inherited
by all sub-expressions within those arguments, unless they are
overridden.</p>
<p>The specific rules by which each element modifies
<kw role="attrib">displaystyle</kw> and/or <kw role="attrib">scriptlevel</kw> are given in the
specification for each element that does so; the complete list of
elements that modify either attribute are: the <quote>scripting</quote> elements
<kw role="element">msub</kw>, <kw role="element">msup</kw>, <kw role="element">msubsup</kw>,
<kw role="element">munder</kw>, <kw role="element">mover</kw>,
<kw role="element">munderover</kw>, and <kw role="element">mmultiscripts</kw>; and the
elements <kw role="element">mfrac</kw>, <kw role="element">mroot</kw>, and
<kw role="element">mtable</kw>.</p>
<p>When <kw role="element">mstyle</kw> is given a
<kw role="attrib">scriptlevel</kw> attribute with no sign, it sets the value of
<kw role="attrib">scriptlevel</kw> 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 <kw role="attrib">scriptlevel</kw> 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
<kw role="element">mstyle</kw>, and is not allowed by any other attribute
on <kw role="element">mstyle</kw>.</p>
<p>Whenever the <kw role="attrib">scriptlevel</kw> is changed, either
automatically or by being explicitly incremented, decremented, or set,
the current font size is multiplied by the value of
<kw role="attrib">scriptsizemultiplier</kw> to the power of the change in
<kw role="attrib">scriptlevel</kw>. For example, if <kw role="attrib">scriptlevel</kw> is
increased by 2, the font size is multiplied by
<kw role="attrib">scriptsizemultiplier</kw> twice in succession; if
<kw role="attrib">scriptlevel</kw> is explicitly set to 2 when it had been 3,
the font size is divided by <kw
role="attrib">scriptsizemultiplier</kw>.
References to <kw role="attrib">fontsize</kw> in this section should be
interpreted to mean either the <kw role="attrib">fontsize</kw> attribute
or the <kw role="attrib">mathsize</kw> attribute.
</p>
<p>The default value of <kw role="attrib">scriptsizemultiplier</kw> is less than
one (in fact, it is approximately the square root of 1/2), resulting
in a smaller font size with increasing <kw role="attrib">scriptlevel</kw>. To
prevent scripts from becoming unreadably small, the font size is never
allowed to go below the value of <kw role="attrib">scriptminsize</kw> as a
result of a change to <kw role="attrib">scriptlevel</kw>, though it can be set
to a lower value using the <kw role="attrib">fontsize</kw> attribute (<specref
ref="presm_commatt"/>) on <kw role="element">mstyle</kw> or on token
elements. If a change to <kw role="attrib">scriptlevel</kw> would cause the font
size to become lower than <kw role="attrib">scriptminsize</kw> using the above
formula, the font size is instead set equal to
<kw role="attrib">scriptminsize</kw> within the sub-expression for which
<kw role="attrib">scriptlevel</kw> was changed.</p>
<p>In the syntax for <kw role="attrib">scriptminsize</kw>, <kw
role="attrib">v-unit</kw> represents a unit of vertical length (as
described in <specref ref="fund_units"/>). The most common unit for specifying font sizes
in typesetting is <code>pt</code> (points).</p>
<p>Explicit changes to the <kw role="attrib">fontsize</kw> attribute have no
effect on the value of <kw role="attrib">scriptlevel</kw>.</p>
</div5>
<div5><head>Further details on <kw role="attrib">scriptlevel</kw> for renderers</head>
<p>For MathML renderers that support CSS style sheets, or some other
analogous style sheet mechanism, absolute or relative changes to
<kw role="attrib">fontsize</kw> (or other attributes) may occur implicitly on
any element in response to a style sheet. Changes to
<kw role="attrib">fontsize</kw> of this kind also have no effect on
<kw role="attrib">scriptlevel</kw>. A style sheet-induced change to
<kw role="attrib">fontsize</kw> overrides <kw role="attrib">scriptminsize</kw> in the same
way as for an explicit change to <kw role="attrib">fontsize</kw> in the
element's start tag (discussed above), whether it is specified in the
style sheet as an absolute or a relative change. (However, any
subsequent <kw role="attrib">scriptlevel</kw>-induced change to
<kw role="attrib">fontsize</kw> will still be affected by it.) As is required
for inherited attributes in CSS, the style sheet-modified
<kw role="attrib">fontsize</kw> is inherited by child elements.</p>
<p>If the same element is subject to both a style sheet-induced and an
automatic (<kw role="attrib">scriptlevel</kw>-related) change to its own
<kw role="attrib">fontsize</kw>, the <kw role="attrib">scriptlevel</kw>-related change is
done first – in fact, in the simplest implementation of the
element-specific rules for <kw role="attrib">scriptlevel</kw>, this change would
be done by the element's parent as part of producing the rendering
properties it passes to the given element, since it is the parent
element that knows whether <kw role="attrib">scriptlevel</kw> should be changed
for each of its child elements.</p>
<p>If the element's own <kw role="attrib">fontsize</kw> is changed by a style
sheet and it also changes <kw role="attrib">scriptlevel</kw> (and thus
<kw role="attrib">fontsize</kw>) for one of its children, the style
sheet-induced change is done first, followed by the change inherited
by that child. If more than one child's <kw role="attrib">scriptlevel</kw> is
changed, the change inherited by each child has no effect on the other
children. (As a mnemonic rule that applies to a <quote>parse tree</quote> of
elements and their children, style sheet-induced changes to
<kw role="attrib">fontsize</kw> can be associated to nodes of the tree, i.e. to
MathML elements, and <kw role="attrib">scriptlevel</kw>-related changes can be
associated to the edges between parent and child elements; then the
order of the associated changes corresponds to the order of nodes and
edges in each path down the tree.) For general information on the
relative order of processing of properties set by style sheets versus by
attributes, see the appropriate subsection of CSS-compatible
attributes in <specref ref="fund_cssatt"/>.</p>
<p>If <kw role="attrib">scriptlevel</kw> is changed incrementally by an
<kw role="element">mstyle</kw> element that also sets certain other
attributes, the overall effect of the changes may depend on the order
in which they are processed. In such cases, the attributes in the
following list should be processed in the following order, regardless
of the order in which they occur in the XML-format attribute list of
the <kw role="element">mstyle</kw> start tag:
<kw role="attrib">scriptsizemultiplier</kw>, <kw role="attrib">scriptminsize</kw>,
<kw role="attrib">scriptlevel</kw>, <kw role="attrib">fontsize</kw>.</p>
<p>Note that <kw role="attrib">scriptlevel</kw> can, in principle, attain any
integral value by being decremented sufficiently, even though it can
only be explicitly set to nonnegative values. Negative values of
<kw role="attrib">scriptlevel</kw> generated in this way are legal and should
work as described, generating font sizes larger than those of the
surrounding expression. Since <kw role="attrib">scriptlevel</kw> is initially 0
and never decreases automatically, it will always be nonnegative
unless it is decremented past 0 using <kw role="element">mstyle</kw>.</p>
<p>Explicit decrements of <kw role="attrib">scriptlevel</kw> after the font size
has been limited by <kw role="attrib">scriptminsize</kw> as described above
would produce undesirable results. This might occur, for example, in a
representation of a continued fraction, in which the scriptlevel was
decremented for part of the denominator back to its value for the
fraction as a whole, if the continued fraction itself was located in a
place that had a high <kw role="attrib">scriptlevel</kw>. To prevent this
problem, MathML renderers should, when decrementing
<kw role="attrib">scriptlevel</kw>, use as the initial font size the value the
font size would have had if it had never been limited by
<kw role="attrib">scriptminsize</kw>. They should not, however, ignore the
effects of explicit settings of <kw role="attrib">fontsize</kw>, even to values
below <kw role="attrib">scriptminsize</kw>.</p>
<p>Since MathML renderers may be unable to make use of arbitrary font
sizes with good results, they may wish to modify the mapping from
scriptlevel to fontsize to produce better renderings in their
judgment. In particular, if fontsizes have to be rounded to available
values, or limited to values within a range, the details of how this
is done are up to the renderer. Renderers should, however, ensure that
a series of incremental changes to <kw role="attrib">scriptlevel</kw> resulting in its
return to the same value for some sub-expression that it had in a
surrounding expression results in the same fontsize for that
sub-expression as for the surrounding expression.</p>
</div5>
<div5><head>Color and background attributes</head>
<p>Color and background attributes are discussed in <specref
ref="presm_color"/>.</p>
</div5>
<div5><head>Precise background region not specified</head>
<p>The suggested MathML visual rendering rules do not define the
precise extent of the region whose background is affected by using the
<kw role="attrib">background</kw> attribute on <kw role="element">mstyle</kw>,
except that, when <kw role="element">mstyle</kw>'s content does not have
negative dimensions and its drawing region is not overlapped by other
drawing due to surrounding negative spacing, this region should lie
behind all the drawing done to render the content of the
<kw role="element">mstyle</kw>, but should not lie behind any of the
drawing done to render surrounding expressions. The effect of overlap
of drawing regions caused by negative spacing on the extent of the
region affected by the <kw role="attrib">background</kw> attribute is not
defined by these rules.</p>
</div5>
<div5><head>Meaning of named mathspaces </head>
<p>The spacing between operators is often one of a small number of
potential values. MathML names these values and allows their values to
be changed. Because the default values for spacing around operators
that are given in the operator dictionary <specref ref="oper-dict"/>
are defined using these named spaces, changing their values will produce
tighter or looser spacing. These values can be used anywhere a <kw
role="attrib">h-unit</kw> or <kw role="attrib">v-unit</kw> unit is
allowed. See <specref ref="fund_units"/>.</p>
<p>
The predefined <kw role="attrib">namedspace</kw>s are:
<kw role="attval">veryverythinmathspace</kw>,
<kw role="attval">verythinmathspace</kw>,
<kw role="attval">thinmathspace</kw>,
<kw role="attval">mediummathspace</kw>,
<kw role="attval">thickmathspace</kw>,
<kw role="attval">verythickmathspace</kw>, or
<kw role="attval">veryverythickmathspace</kw>.
The default values of <kw role="attval">veryverythinmathspace</kw>...
<kw role="attval">veryverythickmathspace</kw> are 1/18em...7/18em,
respectively.</p>
</div5>
</div4>
<div4><head>Examples</head>
<p>The example of limiting the stretchiness of a parenthesis shown in the
section on <mo>,
<eg role='mathml'><![CDATA[
<mrow>
<mo maxsize="1"> ( </mo>
<mfrac> <mi> a </mi> <mi> b </mi> </mfrac>
<mo maxsize="1"> ) </mo>
</mrow>
]]></eg>
</p>
<p>can be rewritten using <kw role="element">mstyle</kw> as:
<eg role='mathml'><![CDATA[
<mstyle maxsize="1">
<mrow>
<mo> ( </mo>
<mfrac> <mi> a </mi> <mi> b </mi> </mfrac>
<mo> ) </mo>
</mrow>
</mstyle>
]]></eg>
</p>
</div4>
</div3>
<div3 id="presm_merror"><head>Error Message (<kw role="element">merror</kw>)</head>
<div4><head>Description</head>
<p>The <kw role="element">merror</kw> element displays its contents as an
<quote>error message</quote>. This might be done, for example, by displaying the
contents in red, flashing the contents, or changing the background
color. The contents can be any expression or expression sequence.</p>
<p><kw role="element">merror</kw> accepts any number of arguments; if
this number is not 1, its contents are treated as a single <quote>inferred
<kw role="element">mrow</kw></quote> as described in <specref ref="presm_reqarg"/>.</p>
<p>The intent of this element is to provide a standard way for
programs that <emph>generate</emph> MathML from other input to report
syntax errors in their input. Since it is anticipated that
preprocessors that parse input syntaxes designed for easy hand entry
will be developed to generate MathML, it is important that they have
the ability to indicate that a syntax error occurred at a certain
point. See <specref ref="interf_error"/>.</p>
<p>The suggested use of <kw role="element">merror</kw> for reporting
syntax errors is for a preprocessor to replace the erroneous part of
its input with an <kw role="element">merror</kw> element containing a
description of the error, while processing the surrounding expressions
normally as far as possible. By this means, the error message will be
rendered where the erroneous input would have appeared, had it been
correct; this makes it easier for an author to determine from the
rendered output what portion of the input was in error.</p>
<p>No specific error message format is suggested here, but as with
error messages from any program, the format should be designed to make
as clear as possible (to a human viewer of the rendered error message)
what was wrong with the input and how it can be fixed. If the
erroneous input contains correctly formatted subsections, it may be
useful for these to be preprocessed normally and included in the error
message (within the contents of the <kw role="element">merror</kw>
element), taking advantage of the ability of
<kw role="element">merror</kw> to contain arbitrary MathML expressions
rather than only text.</p>
</div4>
<div4><head>Attributes</head>
<p>This element only permits <kw role="attrib">id</kw>,
<kw role="attrib">xref</kw>, <kw role="attrib">class</kw> and
<kw role="attrib">style</kw> attributes,
as described in <specref ref="fund_globatt"/>.</p>
</div4>
<div4><head>Example</head>
<p>If a MathML syntax-checking preprocessor
received the input
<eg role='mathml-error'><![CDATA[
<mfraction>
<mrow> <mn> 1 </mn> <mo> + </mo> <msqrt> <mn> 5 </mn> </msqrt> </mrow>
<mn> 2 </mn>
</mfraction>
]]></eg>
which contains the non-MathML element <kw role="element">mfraction</kw>
(presumably in place of the MathML element <kw role="element">mfrac</kw>),
it might generate the error message
<eg role='mathml'><![CDATA[
<merror>
<mtext> Unrecognized element: mfraction;
arguments were: </mtext>
<mrow> <mn> 1 </mn> <mo> + </mo> <msqrt> <mn> 5 </mn> </msqrt> </mrow>
<mtext> and </mtext>
<mn> 2 </mn>
</merror>
]]></eg>
</p>
<p>Note that the preprocessor's input is not, in this case, valid MathML,
but the error message it outputs is valid MathML.</p>
</div4>
</div3>
<div3 id="presm_mpadded"><head>Adjust Space Around Content
(<kw role="element">mpadded</kw>)</head>
<div4><head>Description</head>
<p>An <kw role="element">mpadded</kw> element renders the same as its
content, but with its overall size and other dimensions (such as
baseline position) modified according to its attributes. The
<kw role="element">mpadded</kw> element does not rescale (stretch or
shrink) its content; its only effect is to modify the apparent size
and position of the <quote>bounding box</quote> around its content, so as to
affect the relative position of the content with respect to the
surrounding elements. The name of the element reflects the use of
<kw role="element">mpadded</kw> to effectively add <quote>padding</quote>, or extra
space, around its content. If the <quote>padding</quote> is negative, it is
possible for the content of <kw role="element">mpadded</kw> to be
rendered outside the <kw role="element">mpadded</kw> element's bounding
box; see below for warnings about several potential pitfalls of this
effect.</p>
<p>The <kw role="element">mpadded</kw> element accepts any number of
arguments; if this number is not 1, its contents are treated as a single
<quote>inferred <kw role="element">mrow</kw></quote> as described in
<specref ref="presm_reqarg"/>.</p>
<p>It is suggested that audio renderers add (or shorten) time delays
based on the attributes representing horizontal space
(<kw role="attrib">width</kw> and <kw role="attrib">lspace</kw>).</p>
</div4>
<div4><head>Attributes</head>
<p>In addition to the attributes listed below, this element permits
<kw role="attrib">id</kw>,
<kw role="attrib">xref</kw>, <kw role="attrib">class</kw> and
<kw role="attrib">style</kw> attributes,
as described in <specref ref="fund_globatt"/>.</p>
<table border="1" id="presm_table-mpadded">
<thead>
<tr>
<td>Name</td>
<td>values</td>
<td>default</td>
</tr>
</thead>
<tbody>
<tr>
<td>width</td>
<td>[ + | - ] <emph>unsigned-number</emph>
( % [ <emph>pseudo-unit</emph> ] | <emph>pseudo-unit</emph> | <emph>h-unit</emph> | namedspace )</td>
<td>same as content</td>
</tr>
<tr>
<td>lspace</td>
<td>[ + | - ] <emph>unsigned-number</emph>
( % [ <emph>pseudo-unit</emph> ] | <emph>pseudo-unit</emph> | <emph>h-unit</emph> )</td>
<td>0</td>
</tr>
<tr>
<td>height</td>
<td>[ + | - ] <emph>unsigned-number</emph>
( % [ <emph>pseudo-unit</emph> ] | <emph>pseudo-unit</emph> | <emph>v-unit</emph> )</td>
<td>same as content</td>
</tr>
<tr>
<td>depth</td>
<td>[ + | - ] <emph>unsigned-number</emph>
( % [ <emph>pseudo-unit</emph> ] | <emph>pseudo-unit</emph> | <emph>v-unit</emph> )</td>
<td>same as content</td>
</tr>
</tbody>
</table>
<p>(The <emph>pseudo-unit</emph> syntax symbol is described below.)</p>
<p>These attributes modify the dimensions of the <quote>bounding
box</quote> of the <kw role="element">mpadded</kw> element. The dimensions
(which have the same names as the attributes) are defined in the next
subsection. Depending on the format of the attribute value, a dimension
may be set to a new value, or to an incremented or decremented version of
the content's corresponding dimension. Values may be specified as multiples
or percentages of any of the dimensions of the normal rendering of the
element's content (using so-called <quote>pseudo-units</quote>), or
they can be set directly using standard units <specref
ref="fund_units"/>.</p>
<p>If an attribute value begins with a <code>+</code> or
<code>-</code> sign, it specifies an increment or decrement of the
corresponding dimension by the following length value (interpreted as
explained below). Otherwise, the corresponding dimension is set
directly to the following length value. Note that the <code>+</code>
and <code>-</code> do not mean that the following value is positive or
negative, even when an explicit length unit (<emph>h-unit</emph> or
<emph>v-unit</emph>) is given. In particular, these attributes cannot
directly set a dimension to a negative value.</p>
<p>Length values (after the optional sign, which is not part of the
length value) can be specified in several formats. Each format begins
with an <emph>unsigned-number</emph>, which may be followed by a
<code>%</code> sign and an optional <quote>pseudo-unit</quote> (denoted by
<emph>pseudo-unit</emph> in the attribute syntaxes above), by a
pseudo-unit alone, or by one of the length units
(denoted by <emph>h-unit</emph> or <emph>v-unit</emph>) specified in
<specref ref="fund_units"/>, not including <code>%</code>. The possible
pseudo-units are the keywords <code>width</code>, <code>lspace</code>,
<code>height</code>, and <code>depth</code>; they each represent the
length of the same-named dimension of the <kw role="element">mpadded</kw>
element's content (not of the <kw role="element">mpadded</kw> element
itself). The lengths represented by <emph>h-unit</emph> or
<emph>v-unit</emph> are described in <specref ref="fund_units"/>.</p>
<p>In any of these formats, the length value specified is the product
of the specified number and the length represented by the unit or
pseudo-unit. The result is multiplied by 0.01 if <code>%</code> is given. If no
pseudo-unit is given after <code>%</code>, the one with the same name
as the attribute being specified is assumed.</p>
<p>Some examples of attribute formats using pseudo-units (explicit or
default) are as follows: <code>depth="100% height"</code> and
<code>depth="1.0 height"</code> both set the depth of the
<kw role="element">mpadded</kw> element to the height of its content.
<code>depth="105%"</code> sets the depth to 1.05 times the content's
depth, and either <code>depth="+100%"</code> or
<code>depth="200%"</code> sets the depth to twice the content's
depth.</p>
<p>Dimensions that would be positive if the content was rendered
normally cannot be made negative using <kw role="element">mpadded</kw>; a
positive dimension is set to 0 if it would otherwise become negative.
Dimensions that are initially 0 can be made negative, but this
should generally be avoided. See the warnings below on the use of
negative spacing for <quote>tweaking</quote> or conveying meaning.</p>
<p>The rules given above imply that all of the following attribute
settings have the same effect, which is to leave the content's
dimensions unchanged:
<eg><![CDATA[
<mpadded width="+0em"> ... </mpadded>
<mpadded width="+0%"> ... </mpadded>
<mpadded width="-0em"> ... </mpadded>
<mpadded width="- 0 height"> ... </mpadded>
<mpadded width="100%"> ... </mpadded>
<mpadded width="100% width"> ... </mpadded>
<mpadded width="1 width"> ... </mpadded>
<mpadded width="1.0 width"> ... </mpadded>
<mpadded> ... </mpadded>
]]></eg>
</p>
</div4>
<div4><head>Meanings of dimension attributes</head>
<p>See <specref ref="glossary"/> for further information about some of the
typesetting terms used here.</p>
<p>The <kw role="attrib">width</kw> attribute refers to the overall horizontal
width of a bounding box. By default (i.e. when <kw role="attrib">lspace</kw> is
not modified), the bounding box of the content of an
<kw role="element">mpadded</kw> element should be rendered flush with the
left edge of the <kw role="element">mpadded</kw> element's bounding
box. Thus, increasing <kw role="attrib">width</kw> alone effectively adds space
on the right edge of the box.</p>
<p>The <kw role="attrib">lspace</kw> attribute refers to the amount of space
between the left edge of a bounding box and the start of the rendering of its
contents' bounding box. Unlike the other dimensions,
<kw role="attrib">lspace</kw> does not correspond to a real property of a
bounding box, but exists only transiently during the computations done
by each instance of <kw role="element">mpadded</kw>. It is provided so
that there is a way to add space on the left edge of a bounding
box.</p>
<p>The rationale behind using <kw role="attrib">width</kw> and
<kw role="attrib">lspace</kw> to control horizontal padding instead of more
symmetric attributes, such as a hypothetical <kw role="attrib">rspace</kw> and
<kw role="attrib">lspace</kw>, is that it is desirable to have a <quote>width</quote> pseudo
unit, in part because <quote>width</quote> is an actual property of a bounding
box.</p>
<p>The <kw role="attrib">height</kw> attribute refers to the amount of vertical
space between the baseline (the line along the bottom of most letter
glyphs in normal text rendering) and the top of the bounding box.</p>
<p>The <kw role="attrib">depth</kw> attribute refers to the amount of vertical
space between the bottom of the bounding box and the baseline.</p>
<p>MathML renderers should ensure that, except for the effects of the
attributes, relative spacing between the contents of
<kw role="element">mpadded</kw> and surrounding MathML elements is not
modified by replacing an <kw role="element">mpadded</kw> element with an
<kw role="element">mrow</kw> element with the same content. This holds
even if linebreaking occurs within the <kw role="element">mpadded</kw>
element. However, if an <kw role="element">mpadded</kw> element with
non-default attribute values is subjected to linebreaking, MathML does
not define how its attributes or rendering interact with the
linebreaking algorithm.</p>
</div4>
<div4><head>Warning: nonportability of <quote>tweaking</quote></head>
<p>A likely temptation for the use of the <kw role="element">mpadded</kw>
and <kw role="element">mspace</kw> elements (and perhaps also <kw
role="element">mphantom</kw> and <kw role="element">mtext</kw>) will be
for an author to improve the spacing generated by a specific renderer by
slightly modifying it in specific expressions, i.e. to
<quote>tweak</quote> the rendering.</p>
<p>Authors are strongly warned that <emph>different MathML renderers
may use different spacing rules</emph> for computing the relative
positions of rendered symbols in expressions that have no explicit
modifications to their spacing; if renderer B improves upon renderer
A's spacing rules, explicit spacing added to improve the output
quality of renderer A may produce very poor results in renderer B,
very likely worse than without any <quote>tweaking</quote> at all.</p>
<p>Even when a specific choice of renderer can be assumed, its spacing
rules may be improved in successive versions, so that the effect of
tweaking in a given MathML document may grow worse with time. Also,
when style sheet mechanisms are extended to MathML, even one version
of a renderer may use different spacing rules for users with different
style sheets.</p>
<p>Therefore, it is suggested that MathML markup never use
<kw role="element">mpadded</kw> or <kw role="element">mspace</kw> elements
to tweak the rendering of specific expressions, unless the MathML is
generated solely to be viewed using one specific version of one MathML
renderer, using one specific style sheet (if style sheets are
available in that renderer).</p>
<p>In cases where the temptation to improve spacing proves too strong,
careful use of <kw role="element">mpadded</kw>,
<kw role="element">mphantom</kw>, or the alignment elements (<specref
ref="presm_malign"/>) may give more portable results than the
direct insertion of extra space using <kw role="element">mspace</kw> or
<kw role="element">mtext</kw>. Advice given to the implementors of MathML
renderers might be still more productive, in the long run.</p>
</div4>
<div4><head>Warning: spacing should not be used to convey meaning</head>
<p>MathML elements that permit <quote>negative spacing</quote>, namely
<kw role="element">mspace</kw>, <kw role="element">mpadded</kw>, and
<kw role="element">mtext</kw>, could in theory be used to simulate new
notations or <quote>overstruck</quote> characters by the visual overlap of the
renderings of more than one MathML sub-expression.</p>
<p>This practice is <emph>strongly discouraged in all situations</emph>,
for the following reasons:
<ulist>
<item><p>it will give different results in different MathML renderers
(so the warning about <quote>tweaking</quote> applies);</p>
</item>
<item><p>it is likely to appear much worse than a more standard construct
supported by good renderers;</p>
</item>
<item><p>such expressions are almost certain to be uninterpretable
by audio renderers, computer algebra systems,
text searches for standard symbols,
or other processors of MathML input.</p>
</item>
</ulist>
</p>
<p>More generally, any construct that uses spacing to convey
mathematical meaning, rather than simply as an aid to viewing
expression structure, is discouraged. That is, the constructs that
are discouraged are those that would be interpreted differently by a
human viewer of rendered MathML if all explicit spacing was
removed.</p>
<p>If such constructs are used in spite of this warning, they should
be enclosed in a <kw role="element">semantics</kw> element that also
provides an additional MathML expression that can be interpreted in a
standard way.</p>
<p>For example, the MathML expression
<eg role='mathml'><![CDATA[
<mrow>
<mpadded width="0"> <mi> C </mi> </mpadded>
<mspace width="0.3em"/>
<mtext> | </mtext>
</mrow>
]]></eg>
</p>
<p>forms an overstruck symbol in violation of the policy stated above;
it might be intended to represent the set of complex numbers for a
MathML renderer that lacks support for the standard symbol used for
this purpose. This kind of construct should always be avoided in
MathML, for the reasons stated above; indeed, it should never be
necessary for standard symbols, since a MathML renderer with no better
method of rendering them is free to use overstriking internally, so
that it can still support general MathML input.</p>
<p>However, if for whatever reason such a construct is used in MathML,
it should always be enclosed in a <kw role="element">semantics</kw> element such as
<eg role='mathml'><![CDATA[
<semantics>
<mrow>
<mpadded width="0"> <mi> C </mi> </mpadded>
<mspace width="0.3em"/>
<mtext> | </mtext>
</mrow>
<annotation-xml encoding="MathML-Presentation">
<mi> ℂ </mi>
</annotation-xml>
</semantics>
]]></eg>
</p>
<p>which provides an alternative, standard encoding for the desired
symbol, which is much more easily interpreted than the construct using
negative spacing. (The alternative encoding in this example uses
MathML presentation elements; the content elements described in
<specref ref="contm"/> should also be considered.)</p>
<p>(The above warning also applies to most uses of rendering
attributes to alter the meaning conveyed by an expression, with the
exception of attributes on <kw role="element">mi</kw> (such as
<kw role="attrib">fontweight</kw>) used to distinguish one variable from
another.)</p>
</div4>
</div3>
<div3 id="presm_mphantom"><head>Making Sub-Expressions Invisible (<kw role="element">mphantom</kw>)</head>
<div4><head>Description</head>
<p>The <kw role="element">mphantom</kw> element renders invisibly, but
with the same size and other dimensions, including baseline position,
that its contents would have if they were rendered
normally. <kw role="element">mphantom</kw> can be used to align parts of
an expression by invisibly duplicating sub-expressions.</p>
<p>The <kw role="element">mphantom</kw> element accepts any number of
arguments; if this number is not 1, its contents are treated as a single
<quote>inferred <kw role="element">mrow</kw></quote> formed from all its
arguments, as described in <specref ref="presm_reqarg"/>.</p>
</div4>
<div4><head>Attributes</head>
<p>This element only permits <kw role="attrib">id</kw>,
<kw role="attrib">xref</kw>, <kw role="attrib">class</kw> and
<kw role="attrib">style</kw> attributes,
as described in <specref ref="fund_globatt"/>.</p>
<p>Note that it is possible to wrap both an
<kw role="element">mphantom</kw> and an <kw role="element">mpadded</kw>
element around one MathML expression, as in
<code><mphantom><mpadded attribute-settings>
... </mpadded></mphantom></code>, to change its size and make it
invisible at the same time.</p>
<p>MathML renderers should ensure that the relative spacing between
the contents of an <kw role="element">mphantom</kw> element and the
surrounding MathML elements is the same as it would be if the
<kw role="element">mphantom</kw> element were replaced by an
<kw role="element">mrow</kw> element with the same content. This holds
even if linebreaking occurs within the <kw role="element">mphantom</kw>
element.</p>
<p>For the above reason, <kw role="element">mphantom</kw> is
<emph>not</emph> considered space-like (<specref ref="presm_mspace"/>) unless its
content is space-like, since the suggested rendering rules for
operators are affected by whether nearby elements are space-like. Even
so, the warning about the legal grouping of space-like elements may
apply to uses of <kw role="element">mphantom</kw>.</p>
<p>There is one situation where the preceding rule for rendering an
<kw role="element">mphantom</kw> may not give the desired effect. When an
<kw role="element">mphantom</kw> is wrapped around a subsequence of the
arguments of an <kw role="element">mrow</kw>, the default determination
of the <kw role="attrib">form</kw> attribute for an <kw role="element">mo</kw>
element within the subsequence can change. (See the default value of
the <kw role="attrib">form</kw> attribute described in <specref ref="presm_mo"/>.) It may be
necessary to add an explicit <kw role="attrib">form</kw> attribute to such an
<kw role="element">mo</kw> in these cases. This is illustrated in the
following example.</p>
</div4>
<div4><head>Examples</head>
<p>In this example, <kw role="element">mphantom</kw> is used to ensure
alignment of corresponding parts of the numerator and denominator of a
fraction:
<eg role='mathml'><![CDATA[
<mfrac>
<mrow>
<mi> x </mi>
<mo> + </mo>
<mi> y </mi>
<mo> + </mo>
<mi> z </mi>
</mrow>
<mrow>
<mi> x </mi>
<mphantom>
<mo form="infix"> + </mo>
<mi> y </mi>
</mphantom>
<mo> + </mo>
<mi> z </mi>
</mrow>
</mfrac>
]]></eg>
</p>
<p>This would render as something like
<graphic source="image/f3009.gif" alt="\frac{x+y+z}{x\phantom{+y}\;+z}"/>
rather than as
<graphic source="image/f3010.gif" alt="\frac{x+y+z}{x+z}"/>
</p>
<p>The explicit attribute setting <kw role="attrib">form</kw>="infix" on the
<kw role="element">mo</kw> element inside the <kw role="element">mphantom</kw> sets the
<kw role="attrib">form</kw> attribute to what it would have been in the absence of the
surrounding <kw role="element">mphantom</kw>. This is necessary since
otherwise, the <code>+</code> sign would be interpreted as a prefix
operator, which might have slightly different spacing.</p>
<p>Alternatively, this problem could be avoided without any explicit
attribute settings, by wrapping each of the arguments
<code><mo>+</mo></code> and <code><mi>y</mi></code> in its
own <kw role="element">mphantom</kw> element, i.e.
<eg role='mathml'><![CDATA[
<mfrac>
<mrow>
<mi> x </mi>
<mo> + </mo>
<mi> y </mi>
<mo> + </mo>
<mi> z </mi>
</mrow>
<mrow>
<mi> x </mi>
<mphantom>
<mo> + </mo>
</mphantom>
<mphantom>
<mi> y </mi>
</mphantom>
<mo> + </mo>
<mi> z </mi>
</mrow>
</mfrac>
]]></eg>
</p>
</div4>
</div3>
<div3 id="presm_mfenced"><head>Expression Inside Pair of Fences
(<kw role="element">mfenced</kw>)</head>
<div4><head>Description</head>
<p>The <kw role="element">mfenced</kw> element provides a convenient form
in which to express common constructs involving fences (i.e. braces,
brackets, and parentheses), possibly including separators (such as
comma) between the arguments.</p>
<p>For example, <code><![CDATA[<mfenced> <mi>x</mi> </mfenced>]]></code>
renders as <quote>(<mi>x</mi>)</quote> and is equivalent to
<eg role='mathml'><![CDATA[
<mrow> <mo> ( </mo> <mi>x</mi> <mo> ) </mo> </mrow>
]]></eg>
and
<code><![CDATA[<mfenced> <mi>x</mi> <mi>y</mi> </mfenced>]]></code>
renders as <quote>(<mi>x</mi>, <mi>y</mi>)</quote>
and is equivalent to
<eg role='mathml'><![CDATA[
<mrow>
<mo> ( </mo>
<mrow> <mi>x</mi> <mo>,</mo> <mi>y</mi> </mrow>
<mo> ) </mo>
</mrow>
]]></eg>
</p>
<p>Individual fences or separators are represented using
<kw role="element">mo</kw> elements, as described in <specref
ref="presm_mo"/>. Thus, any <kw role="element">mfenced</kw>
element is completely equivalent to an expanded form described below;
either form can be used in MathML, at the convenience of an author or
of a MathML-generating program. A MathML renderer is required to
render either of these forms in exactly the same way.</p>
<p>In general, an <kw role="element">mfenced</kw> element can contain
zero or more arguments, and will enclose them between fences in an
<kw role="element">mrow</kw>; if there is more than one argument, it will
insert separators between adjacent arguments, using an additional
nested <kw role="element">mrow</kw> around the arguments and separators
for proper grouping (<specref ref="presm_mrow"/>). The general expanded form is
shown below. The fences and separators will be parentheses and comma
by default, but can be changed using attributes, as shown in the
following table.</p>
</div4>
<div4><head>Attributes</head>
<p>In addition to the attributes listed below, this element permits
<kw role="attrib">id</kw>,
<kw role="attrib">xref</kw>, <kw role="attrib">class</kw> and
<kw role="attrib">style</kw> attributes,
as described in <specref ref="fund_globatt"/>.</p>
<table border="1">
<thead>
<tr>
<td>Name</td>
<td>values</td>
<td>default</td>
</tr>
</thead>
<tbody>
<tr>
<td>open</td>
<td>string</td>
<td>(</td>
</tr>
<tr>
<td>close</td>
<td>string</td>
<td>)</td>
</tr>
<tr>
<td>separators</td>
<td>character *</td>
<td>,</td>
</tr>
</tbody>
</table>
<p>A generic <kw role="element">mfenced</kw> element, with all attributes
explicit, looks as follows:
<eg><![CDATA[
<mfenced open="opening-fence"
close="closing-fence"
separators="sep#1 sep#2 ... sep#(n-1)" >
arg#1
...
arg#n
</mfenced>
]]></eg>
</p>
<p>The <kw role="attrib">opening-fence</kw> and <kw role="attrib">closing-fence</kw> are
arbitrary strings. (Since they are used as the content of
<kw role="element">mo</kw> elements, any whitespace they contain will be
trimmed and collapsed as described in <specref ref="fund_collapse"/>.) </p>
<p>The value of <kw role="attrib">separators</kw> is a sequence of zero or more
separator characters (or entity references), optionally separated by
whitespace. Each <code>sep#i</code> consists of exactly
one character or entity reference. Thus, <code>separators=",;"</code>
is equivalent to <code>separators=" , ; "</code>.</p>
<p>The general <kw role="element">mfenced</kw> element shown above is
equivalent to the following expanded form:
<eg><![CDATA[
<mrow>
<mo fence="true"> opening-fence </mo>
<mrow>
arg#1
<mo separator="true"> sep#1 </mo>
...
<mo separator="true"> sep#(n-1) </mo>
arg#n
</mrow>
<mo fence="true"> closing-fence </mo>
</mrow>
]]></eg>
</p>
<p>Each argument except the last is followed by a separator. The inner
<kw role="element">mrow</kw> is added for proper grouping, as described in
<specref ref="presm_mrow"/>.</p>
<p>When there is only one argument, the above form has no separators;
since <code><mrow> arg#1 </mrow></code> is equivalent to
<code>arg#1</code> (as described in <specref
ref="presm_mrow"/>), this case is also equivalent to:
<eg><![CDATA[
<mrow>
<mo fence="true"> opening-fence </mo>
arg#1
<mo fence="true"> closing-fence </mo>
</mrow>
]]></eg>
</p>
<p>If there are too many separator characters, the extra ones are
ignored. If separator characters are given, but there are too few, the
last one is repeated as necessary. Thus, the default value of
<kw role="attrib">separators</kw>="," is equivalent to
<kw role="attrib">separators</kw>=",,", <kw role="attrib">separators</kw>=",,,", etc. If
there are no separator characters provided but some are needed, for
example if <kw role="attrib">separators</kw>=" " or "" and there is more than
one argument, then no separator elements are inserted at all – that
is, the elements <code><mo separator="true"> sep#i
</mo></code> are left out entirely. Note that this is different
from inserting separators consisting of <kw role="element">mo</kw>
elements with empty content.</p>
<p>Finally, for the case with no arguments, i.e.
<eg><![CDATA[
<mfenced open="opening-fence"
close="closing-fence"
separators="anything" >
</mfenced>
]]></eg>
the equivalent expanded form is defined to include just
the fences within an <kw role="element">mrow</kw>:
<eg><![CDATA[
<mrow>
<mo fence="true"> opening-fence </mo>
<mo fence="true"> closing-fence </mo>
</mrow>
]]></eg>
</p>
<p>Note that not all <quote>fenced expressions</quote> can be encoded by an
<kw role="element">mfenced</kw> element. Such exceptional expressions
include those with an <quote>embellished</quote> separator or fence or one
enclosed in an <kw role="element">mstyle</kw> element, a missing or extra
separator or fence, or a separator with multiple content
characters. In these cases, it is necessary to encode the expression
using an appropriately modified version of an expanded form. As
discussed above, it is always permissible to use the expanded form
directly, even when it is not necessary. In particular, authors cannot
be guaranteed that MathML preprocessors won't replace occurrences of
<kw role="element">mfenced</kw> with equivalent expanded forms.</p>
<p>Note that the equivalent expanded forms shown above include
attributes on the <kw role="element">mo</kw> elements that identify them
as fences or separators. Since the most common choices of fences and
separators already occur in the operator dictionary with those
attributes, authors would not normally need to specify those
attributes explicitly when using the expanded form directly. Also, the
rules for the default <kw role="attrib">form</kw> attribute (<specref ref="presm_mo"/>)
cause the opening and closing fences to be effectively given the
values <kw role="attrib">form</kw>="prefix" and <kw role="attrib">form</kw>="postfix"
respectively, and the separators to be given the value
<kw role="attrib">form</kw>="infix".</p>
<p>Note that it would be incorrect to use <kw role="element">mfenced</kw>
with a separator of, for instance, <quote>+</quote>, as an abbreviation for an
expression using <quote>+</quote> as an ordinary operator, e.g.
<eg role='mathml'><![CDATA[
<mrow>
<mi>x</mi> <mo>+</mo> <mi>y</mi> <mo>+</mo> <mi>z</mi>
</mrow>
]]></eg>
This is because the <code>+</code> signs would be treated as separators,
not infix operators. That is, it would render as if they were marked up as
<code><![CDATA[<mo separator="true">+</mo>]]></code>, which might therefore
render inappropriately.</p>
</div4>
<div4><head>Examples</head>
<p>(<mi>a</mi>+<mi>b</mi>)
<eg role='mathml'><![CDATA[
<mfenced>
<mrow>
<mi> a </mi>
<mo> + </mo>
<mi> b </mi>
</mrow>
</mfenced>
]]></eg>
</p>
<p>Note that the above <kw role="element">mrow</kw> is necessary so that
the <kw role="element">mfenced</kw> has just one argument. Without it, this
would render incorrectly as <quote>(<mi>a</mi>, +,
<mi>b</mi>)</quote>.</p>
<p>[0,1)
<eg role='mathml'><![CDATA[
<mfenced open="[">
<mn> 0 </mn>
<mn> 1 </mn>
</mfenced>
]]></eg>
</p>
<p><mi>f</mi>(<mi>x</mi>,<mi>y</mi>)
<eg role='mathml'><![CDATA[
<mrow>
<mi> f </mi>
<mo> ⁡ </mo>
<mfenced>
<mi> x </mi>
<mi> y </mi>
</mfenced>
</mrow>
]]></eg>
</p>
</div4>
</div3>
<div3 id="presm_menclose"><head>Enclose Expression Inside Notation
(<kw role="element">menclose</kw>)</head>
<div4><head>Description</head>
<p>The <kw role="element">menclose</kw> element renders its content
inside the enclosing notation specified by its <kw
role="attrib">notation</kw> attribute.
<kw role="element">menclose</kw> accepts any number of arguments; if
this number is not 1, its contents are treated as a single <quote>inferred
<kw role="element">mrow</kw></quote> containing its arguments,
as described in <specref ref="presm_reqarg"/>. </p>
</div4>
<div4><head>Attributes</head>
<p>In addition to the attributes listed below, this element permits
<kw role="attrib">id</kw>,
<kw role="attrib">xref</kw>, <kw role="attrib">class</kw> and
<kw role="attrib">style</kw> attributes,
as described in <specref ref="fund_globatt"/>.</p>
<table border="1">
<thead>
<tr>
<td>Name</td>
<td>values</td>
<td>default</td>
</tr>
</thead>
<tbody>
<tr>
<td>notation</td>
<td>longdiv | actuarial | radical </td>
<td>longdiv</td>
</tr>
</tbody>
</table>
<p>When <kw role="attrib">notation</kw> has the value <kw
role="attval">longdiv</kw>, the contents are drawn enclosed by a long
division symbol. A complete example of long division is accomplished
by also using <kw role="element">mtable</kw> and <kw
role="element">malign</kw>. When <kw role="attrib">notation</kw> is
specified as <kw role="attval">actuarial</kw>, the contents are drawn
enclosed by an actuarial symbol. The case of <kw
role="attrib">notation</kw>=<kw role="attval">radical</kw> is
equivalent to the <kw role="element">msqrt</kw> schema.</p>
</div4>
<div4><head>Examples</head>
<p>The following markup might be used to encode an elementary US-style
long division problem.</p>
<p><eg role='mathml'><![CDATA[
<mtable columnspacing='0' rowspacing='0'>
<mtr>
<mtd></mtd>
<mtd columnalign='right'><mn>10</mn></mtd>
</mtr>
<mtr>
<mtd columnalign='right'><mn>131</mn></mtd>
<mtd columnalign='right'>
<menclose notation='longdiv'><mn>1413</mn></menclose>
</mtd>
</mtr>
<mtr>
<mtd></mtd>
<mtd columnalign='right'>
<mrow>
<munder>
<mn>131</mn>
<mo> _ </mo>
</munder>
<mphantom><mn>3</mn></mphantom>
</mrow>
</mtd>
</mtr>
<mtr>
<mtd></mtd>
<mtd columnalign='right'><mn>103</mn></mtd>
</mtr>
</mtable>
]]></eg></p>
<p>This might be rendered roughly as:
<graphic role="display" source="image/f3011.gif"
alt="\begin{array}{rl}
& \phantom{)14}10 \\
131 & \overline{)1413\,} \\
& \phantom{)}\underline{131\phantom{g}} \\
& \phantom{)1}103
\end{array}"/>
</p>
<p>An example of using <kw role="element">menclose</kw> for actuarial
notation is
<eg role='mathml'><![CDATA[
<msub>
<mi>a</mi>
<mrow>
<menclose notation='actuarial'>
<mi>n</mi>
</menclose>
<mo>⁢</mo>
<mi>i</mi>
</mrow>
</msub>
]]></eg>
which renders roughly as
<graphic role="display" source="image/f3012.gif"
alt="\begin{array}{l@{}l}
\phantom{x}a & \\
\overline{\phantom{x}n\phantom{|}}| & i
\end{array}"/>
</p>
</div4>
</div3>
</div2>
<div2 id="presm_scrlim"><head>Script and Limit Schemata</head>
<p>The elements described in this section position one or more scripts
around a base. Attaching various kinds of scripts and embellishments to
symbols is a very common notational device in mathematics. For purely
visual layout, a single general-purpose 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.</p>
<p>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 for placing
accents and lines above or below the base. The rules for rendering accents
differ from those for overscripts and underscripts, and this difference can
be controlled with the <kw role="attrib">accent</kw> and <kw
role="attrib">accentunder</kw> attributes, as described in the appropriate
sections below.</p>
<p>Rendering of scripts is affected by the <kw
role="attrib">scriptlevel</kw> and <kw role="attrib">displaystyle</kw>
attributes, which are part of the environment inherited by the rendering
process of every MathML expression, and are described under <kw
role="element">mstyle</kw> (<specref ref="presm_mstyle"/>). These
attributes cannot be given explicitly on a scripting element, but can be
specified on the start tag of a surrounding <kw role="element">mstyle</kw>
element if desired.</p>
<p>MathML also provides an element for attachment of tensor indices.
Tensor indices are distinct from ordinary subscripts and superscripts in
that they must align in vertical columns. Tensor indices can also occur in
prescript positions.</p>
<p>Because presentation elements should be used to describe the abstract
notational structure of expressions, it is important that the base
expression in all <quote>scripting</quote> elements (i.e. the first
argument expression) should be the entire expression that is being
scripted, not just the rightmost character. For example,
(<mi>x</mi>+<mi>y</mi>)<sup>2</sup> should be written as:
<eg role='mathml'><![CDATA[
<msup>
<mrow>
<mo> ( </mo>
<mrow>
<mi> x </mi>
<mo> + </mo>
<mi> y </mi>
</mrow>
<mo> ) </mo>
</mrow>
<mn> 2 </mn>
</msup>
]]></eg>
</p>
<div3 id="presm_msub"><head>Subscript (<kw role="element">msub</kw>)</head>
<div4><head>Description</head>
<p>The syntax for the <kw role="element">msub</kw> element is:
<eg>
<msub> <emph>base</emph> <emph>subscript</emph> </msub>
</eg></p>
</div4>
<div4><head>Attributes</head>
<p>In addition to the attributes listed below, this element permits
<kw role="attrib">id</kw>,
<kw role="attrib">xref</kw>, <kw role="attrib">class</kw> and
<kw role="attrib">style</kw> attributes,
as described in <specref ref="fund_globatt"/>.</p>
<table border="1">
<thead>
<tr>
<td>Name</td>
<td>values</td>
<td>default</td>
</tr>
</thead>
<tbody>
<tr>
<td>subscriptshift</td>
<td>number v-unit</td>
<td>automatic (typical unit is ex)</td>
</tr>
</tbody>
</table>
<p>The <kw role="attrib">subscriptshift</kw> attribute specifies the minimum
amount to shift the baseline of <emph>subscript</emph> down.</p>
<p><emph>v-unit</emph> represents a unit of vertical length (see
<specref ref="fund_units"/>).</p>
<p>The <kw role="element">msub</kw> element increments
<kw role="attrib">scriptlevel</kw> by 1, and sets <kw role="attrib">displaystyle</kw> to
<kw role="attval">false</kw>, within <emph>subscript</emph>, but leaves both attributes
unchanged within <emph>base</emph>. (These attributes are inherited by
every element through its rendering environment, but can be set
explicitly only on <kw role="element">mstyle</kw>; see <specref
ref="presm_mstyle"/>.)</p>
</div4>
</div3>
<div3 id="presm_msup"><head>Superscript (<kw role="element">msup</kw>)</head>
<div4><head>Description</head>
<p>The syntax for the <kw role="element">msup</kw> element is:
<eg>
<msup> <emph>base</emph> <emph>superscript</emph> </msup>
</eg></p>
</div4>
<div4><head>Attributes</head>
<p>In addition to the attributes listed below, this element permits
<kw role="attrib">id</kw>,
<kw role="attrib">xref</kw>, <kw role="attrib">class</kw> and
<kw role="attrib">style</kw> attributes,
as described in <specref ref="fund_globatt"/>.</p>
<table border="1">
<thead>
<tr>
<td>Name</td>
<td>values</td>
<td>default</td>
</tr>
</thead>
<tbody>
<tr>
<td>superscriptshift</td>
<td>number v-unit</td>
<td>automatic (typical unit is ex)</td>
</tr>
</tbody>
</table>
<p>The <kw role="attrib">superscriptshift</kw> attribute specifies the
minimum amount to shift the baseline of <emph>superscript</emph> up.</p>
<p><emph>v-unit</emph> represents a unit of vertical length (see <specref
ref="fund_units"/>).</p>
<p>The <kw role="element">msup</kw> element increments <kw
role="attrib">scriptlevel</kw> by 1, and sets <kw
role="attrib">displaystyle</kw> to <kw role="attval">false</kw>, within
<emph>superscript</emph>, but leaves both attributes unchanged within
<emph>base</emph>. (These attributes are inherited by every element through
its rendering environment, but can be set explicitly only on <kw
role="element">mstyle</kw>; see <specref ref="presm_mstyle"/>.) </p>
</div4>
</div3>
<div3 id="presm_msubsup"><head>Subscript-superscript Pair (<kw role="element">msubsup</kw>)</head>
<div4><head>Description</head>
<p>The <kw role="element">msubsup</kw> element is used to attach both a subscript and
superscript to a base expression. Note that both scripts are
positioned tight against the base:
<graphic role="inline" source="image/f3013.gif" alt="x_1{}^2"/>
versus
<graphic role="inline" source="image/f3014.gif" alt="x_1^2"/>.</p>
<p>The syntax for the <kw role="element">msubsup</kw> element is:
<eg>
<msubsup> <emph>base</emph> <emph>subscript</emph> <emph>superscript</emph> </msubsup>
</eg>
</p>
</div4>
<div4><head>Attributes</head>
<p>In addition to the attributes listed below, this element permits
<kw role="attrib">id</kw>,
<kw role="attrib">xref</kw>, <kw role="attrib">class</kw> and
<kw role="attrib">style</kw> attributes,
as described in <specref ref="fund_globatt"/>.</p>
<table border="1">
<thead>
<tr>
<td>Name</td>
<td>values</td>
<td>default</td>
</tr>
</thead>
<tbody>
<tr>
<td>subscriptshift</td>
<td>number v-unit</td>
<td>automatic (typical unit is ex)</td>
</tr>
<tr>
<td>superscriptshift</td>
<td>number v-unit</td>
<td>automatic (typical unit is ex)</td>
</tr>
</tbody>
</table>
<p>The <kw role="attrib">subscriptshift</kw> attribute specifies the minimum
amount to shift the baseline of <emph>subscript</emph> down. The
<kw role="attrib">superscriptshift</kw> attribute specifies the minimum amount
to shift the baseline of <emph>superscript</emph> up.</p>
<p><emph>v-unit</emph> represents a unit of vertical length (see <specref
ref="fund_units"/>).</p>
<p>The <kw role="element">msubsup</kw> element increments
<kw role="attrib">scriptlevel</kw> by 1, and sets <kw role="attrib">displaystyle</kw> to
<kw role="attval">false</kw>, within <emph>subscript</emph> and <emph>superscript</emph>,
but leaves both attributes unchanged within <emph>base</emph>. (These
attributes are inherited by every element through its rendering
environment, but can be set explicitly only on
<kw role="element">mstyle</kw>; see <specref ref="presm_mstyle"/>.)
</p>
</div4>
<div4><head>Examples</head>
<p>The <kw role="element">msubsup</kw> is most commonly used for adding
sub/superscript pairs to identifiers as illustrated above. However,
another important use is placing limits on certain large operators
whose limits are traditionally displayed in the script positions even
when rendered in display style. The most common of these is the
integral. For example,</p>
<p><graphic role="display" source="image/f3015.gif" alt="\int\nolimits_0^1 \eulere^x \,\diffd x"/>
would be represented as
<eg role='mathml'><![CDATA[
<mrow>
<msubsup>
<mo> ∫ </mo>
<mn> 0 </mn>
<mn> 1 </mn>
</msubsup>
<mrow>
<msup>
<mi> ⅇ </mi>
<mi> x </mi>
</msup>
<mo> ⁢ </mo>
<mrow>
<mo> ⅆ </mo>
<mi> x </mi>
</mrow>
</mrow>
</mrow>
]]></eg>
</p>
</div4>
</div3>
<div3 id="presm_munder"><head>Underscript (<kw role="element">munder</kw>)</head>
<div4><head>Description</head>
<p>The syntax for the <kw role="element">munder</kw> element is:
<eg>
<munder> <emph>base</emph> <emph>underscript</emph> </munder>
</eg></p>
</div4>
<div4><head>Attributes</head>
<p>In addition to the attributes listed below, this element permits
<kw role="attrib">id</kw>,
<kw role="attrib">xref</kw>, <kw role="attrib">class</kw> and
<kw role="attrib">style</kw> attributes,
as described in <specref ref="fund_globatt"/>.</p>
<table border="1">
<thead>
<tr>
<td>Name</td>
<td>values</td>
<td>default</td>
</tr>
</thead>
<tbody>
<tr>
<td>accentunder</td>
<td>true | false</td>
<td>automatic</td>
</tr>
</tbody>
</table>
<p>The <kw role="attrib">accentunder</kw> attribute controls whether
<emph>underscript</emph> is drawn as an <quote>accent</quote> or as a limit. The
main difference between an accent and a limit is that the limit is
reduced in size whereas an accent is the same size as the base. A
second difference is that the accent is drawn closer to the base.</p>
<p>The default value of <kw role="attrib">accentunder</kw> is false, unless
<emph>underscript</emph> is an <kw role="element">mo</kw> element or an
embellished operator (see <specref ref="presm_mo"/>). If
<emph>underscript</emph> is an <kw role="element">mo</kw> element, the
value of its <kw role="attrib">accent</kw> attribute is used as the default
value of <kw role="attrib">accentunder</kw>. If <emph>underscript</emph> is an
embellished operator, the <kw role="attrib">accent</kw> attribute of the
<kw role="element">mo</kw> element at its core is used as the default
value. As with all attributes, an explicitly given value overrides
the default.</p>
<p>Here is an example (accent versus underscript):
<graphic role="inline" source="image/f3016.gif" alt="\underbrace{x+y+z}"/> versus
<graphic role="inline" source="image/f3017.gif" alt="\underbrace{\strut x+y+z}"/>.
The MathML representation for this example is shown below.</p>
<p>If the base is an operator with <kw role="attrib">movablelimits</kw>=<kw
role="attval">true</kw> (or an embellished operator whose <kw
role="element">mo</kw> element core has <kw
role="attrib">movablelimits</kw>=<kw role="attval">true</kw>), and <kw
role="attrib">displaystyle</kw>=<kw role="attval">false</kw>, then
<emph>underscript</emph> is drawn in a subscript position. In this case,
the <kw role="attrib">accentunder</kw> attribute is ignored. This is often
used for limits on symbols such as <kw role="entity">sum</kw>.</p>
<p>Within <emph>underscript</emph>, <kw role="element">munder</kw> always
sets <kw role="attrib">displaystyle</kw> to <kw role="attval">false</kw>, but increments
<kw role="attrib">scriptlevel</kw> by 1 only when <kw role="attrib">accentunder</kw> is
<kw role="attval">false</kw>. Within <emph>base</emph>, it always leaves both attributes
unchanged. (These attributes are inherited by every element through
its rendering environment, but can be set explicitly only on
<kw role="element">mstyle</kw>; see <specref ref="presm_mstyle"/>.)
</p>
</div4>
<div4><head>Examples</head>
<p>The MathML representation for the example shown above is:
<eg role='mathml'><![CDATA[
<mrow>
<munder accentunder="true">
<mrow>
<mi> x </mi>
<mo> + </mo>
<mi> y </mi>
<mo> + </mo>
<mi> z </mi>
</mrow>
<mo> ⏟ </mo>
</munder>
<mtext> versus </mtext>
<munder accentunder="false">
<mrow>
<mi> x </mi>
<mo> + </mo>
<mi> y </mi>
<mo> + </mo>
<mi> z </mi>
</mrow>
<mo> ⏟ </mo>
</munder>
</mrow>
]]></eg>
</p>
</div4>
</div3>
<div3 id="presm_mover"><head>Overscript (<kw role="element">mover</kw>)</head>
<div4><head>Description</head>
<p>The syntax for the <kw role="element">mover</kw> element is:
<eg>
<mover> <emph>base</emph> <emph>overscript</emph> </mover>
</eg></p>
</div4>
<div4><head>Attributes</head>
<p>In addition to the attributes listed below, this element permits
<kw role="attrib">id</kw>,
<kw role="attrib">xref</kw>, <kw role="attrib">class</kw> and
<kw role="attrib">style</kw> attributes,
as described in <specref ref="fund_globatt"/>.</p>
<p>
<table border="1">
<thead>
<tr>
<td>Name</td>
<td>values</td>
<td>default</td>
</tr>
</thead>
<tbody>
<tr>
<td>accent</td>
<td>true | false</td>
<td>automatic</td>
</tr>
</tbody>
</table>
</p>
<p>The <kw role="attrib">accent</kw> attribute controls whether
<emph>overscript</emph> is drawn as an <quote>accent</quote> (diacritical mark) or
as a limit. The main difference between an accent and a limit is that
the limit is reduced in size whereas an accent is the same size as the
base. A second difference is that the accent is drawn closer to the
base. This is shown below (accent versus limit):
<graphic role="inline" source="image/f3018.gif" alt="\hat{x}"/> versus
<graphic role="inline" source="image/f3019.gif" alt="\hat{\strut x}"/>.</p>
<p>These differences also apply to <quote>mathematical accents</quote> such as
bars over expressions:
<graphic role="inline" source="image/f3020.gif" alt="\overbrace{x+y+z}"/> versus
<graphic role="inline" source="image/f3021.gif" alt="\overbrace{\strut x+y+z}"/>.
The MathML representation for each of these examples is shown below.</p>
<p>The default value of <emph>accent</emph> is false, unless
<emph>overscript</emph> is an <kw role="element">mo</kw> element or an
embellished operator (see <specref ref="presm_mo"/>). If
<emph>overscript</emph> is an <kw role="element">mo</kw> element, the value
of its <kw role="attrib">accent</kw> attribute is used as the default value
of <kw role="attrib">accent</kw> for <kw role="element">mover</kw>. If
<emph>overscript</emph> is an embellished operator, the <kw
role="attrib">accent</kw> attribute of the <kw role="element">mo</kw>
element at its core is used as the default value.</p>
<p>If the base is an operator with <kw role="attrib">movablelimits</kw>=<kw
role="attval">true</kw> (or an embellished operator whose <kw
role="element">mo</kw> element core has <kw
role="attrib">movablelimits</kw>=<kw role="attval">true</kw>), and <kw
role="attrib">displaystyle</kw>=<kw role="attval">false</kw>, then
<emph>overscript</emph> is drawn in a superscript position. In this case,
the <kw role="attrib">accent</kw> attribute is ignored. This is often used
for limits on symbols such as <kw role="entity">sum</kw>.</p>
<p>Within <emph>overscript</emph>, <kw role="element">mover</kw> always
sets <kw role="attrib">displaystyle</kw> to <kw role="attval">false</kw>,
but increments <kw role="attrib">scriptlevel</kw> by 1 only when <kw
role="attrib">accent</kw> is <kw role="attval">false</kw>. Within
<emph>base</emph>, it always leaves both attributes unchanged. (These
attributes are inherited by every element through its rendering
environment, but can be set explicitly only on <kw
role="element">mstyle</kw>; see <specref ref="presm_mstyle"/>.)
</p>
</div4>
<div4><head>Examples</head>
<p>The MathML representation for the examples shown above is:
<eg role='mathml'><![CDATA[
<mrow>
<mover accent="true">
<mi> x </mi>
<mo> ^ </mo>
</mover>
<mtext> versus </mtext>
<mover accent="false">
<mi> x </mi>
<mo> ^ </mo>
</mover>
</mrow>
]]></eg>
<eg role='mathml'><![CDATA[
<mrow>
<mover accent="true">
<mrow>
<mi> x </mi>
<mo> + </mo>
<mi> y </mi>
<mo> + </mo>
<mi> z </mi>
</mrow>
<mo> ‾ </mo>
</mover>
<mtext> versus </mtext>
<mover accent="false">
<mrow>
<mi> x </mi>
<mo> + </mo>
<mi> y </mi>
<mo> + </mo>
<mi> z </mi>
</mrow>
<mo> ‾ </mo>
</mover>
</mrow>
]]></eg>
</p>
</div4>
</div3>
<div3 id="presm_munderover"><head>Underscript-overscript Pair
(<kw role="element">munderover</kw>)</head>
<div4><head>Description</head>
<p>The syntax for the <kw role="element">munderover</kw> element is:
<eg>
<munderover> <emph>base</emph> <emph>underscript</emph> <emph>overscript</emph> </munderover>
</eg></p>
</div4>
<div4><head>Attributes</head>
<p>In addition to the attributes listed below, this element permits
<kw role="attrib">id</kw>,
<kw role="attrib">xref</kw>, <kw role="attrib">class</kw> and
<kw role="attrib">style</kw> attributes,
as described in <specref ref="fund_globatt"/>.</p>
<table border="1">
<thead>
<tr>
<td>Name</td>
<td>values</td>
<td>default</td>
</tr>
</thead>
<tbody>
<tr>
<td>accent</td>
<td>true | false</td>
<td>automatic</td>
</tr>
<tr>
<td>accentunder</td>
<td>true | false</td>
<td>automatic</td>
</tr>
</tbody>
</table>
<p>The <kw role="element">munderover</kw> element is used so that the
underscript and overscript are vertically spaced equally in relation
to the base and so that they follow the slant of the base as in the
second expression shown below:</p>
<p><graphic role="display" source="image/f3022.gif" alt="\int_0^{\!\!\!\infty}"/>
versus
<graphic role="display" source="image/f3023.gif" alt="\int_0^{\infty}"/>
The MathML representation for this example is shown below.</p>
<p>The difference in the vertical spacing is too small to be noticed on a
low resolution display at a normal font size, but is noticeable on a higher
resolution device such as a printer and when using large font sizes. In
addition to the visual differences, attaching both the underscript and
overscript to the same base more accurately reflects the semantics of the
expression.</p>
<p>The <kw role="attrib">accent</kw> and <kw role="attrib">accentunder</kw>
attributes have the same effect as the attributes with the same names on
<kw role="element">mover</kw> (<specref ref="presm_mover"/>) and <kw
role="element">munder</kw> (<specref ref="presm_munder"/>),
respectively. Their default values are also computed in the same manner as
described for those elements, with the default value of <kw
role="attrib">accent</kw> depending on <emph>overscript</emph> and the
default value of <kw role="attrib">accentunder</kw> depending on
<emph>underscript</emph>.</p>
<p>If the base is an operator with <kw role="attrib">movablelimits</kw>=<kw
role="attval">true</kw> (or an embellished operator whose <kw
role="element">mo</kw> element core has <kw
role="attrib">movablelimits</kw>=<kw role="attval">true</kw>), and <kw
role="attrib">displaystyle</kw>=<kw role="attval">false</kw>, then
<emph>underscript</emph> and <emph>overscript</emph> are drawn in a
subscript and superscript position, respectively. In this case, the <kw
role="attrib">accent</kw> and <kw role="attrib">accentunder</kw> attributes
are ignored. This is often used for limits on symbols such as <kw
role="entity">sum</kw>.</p>
<p>Within <emph>underscript</emph>, <kw role="element">munderover</kw>
always sets <kw role="attrib">displaystyle</kw> to <kw
role="attval">false</kw>, but increments <kw role="attrib">scriptlevel</kw>
by 1 only when <kw role="attrib">accentunder</kw> is <kw
role="attval">false</kw>. Within <emph>overscript</emph>, <kw
role="element">munderover</kw> always sets <kw
role="attrib">displaystyle</kw> to <kw role="attval">false</kw>, but
increments <kw role="attrib">scriptlevel</kw> by 1 only when <kw
role="attrib">accent</kw> is <kw role="attval">false</kw>. Within
<emph>base</emph>, it always leaves both attributes unchanged. (These
attributes are inherited by every element through its rendering
environment, but can be set explicitly only on <kw
role="element">mstyle</kw>; see <specref ref="presm_mstyle"/>).</p>
</div4>
<div4><head>Examples</head>
<p>The MathML representation for the example shown above with the first
expression made using separate <kw role="element">munder</kw> and
<kw role="element">mover</kw> elements, and the second one using an
<kw role="element">munderover</kw> element, is:
<eg role='mathml'><![CDATA[
<mrow>
<mover>
<munder>
<mo> ∫ </mo>
<mn> 0 </mn>
</munder>
<mi> ∞ </mi>
</mover>
<mtext> versus </mtext>
<munderover>
<mo> ∫ </mo>
<mn> 0 </mn>
<mi> ∞ </mi>
</munderover>
</mrow>
]]></eg>
</p>
</div4>
</div3>
<div3 id="presm_mmultiscripts"><head>Prescripts and Tensor Indices
(<kw role="element">mmultiscripts</kw>)</head>
<div4><head>Description</head>
<p>The syntax for the <kw role="element">mmultiscripts</kw> element is:
<eg>
<mmultiscripts>
<emph>base</emph>
(<emph>subscript superscript</emph>)*
[ <mprescripts/> (<emph>presubscript presuperscript</emph>)* ]
</mmultiscripts>
</eg>
</p>
<p>Presubscripts and tensor notations are represented by a single
element, <kw role="element">mmultiscripts</kw>. This element allows the
representation of any number of vertically-aligned pairs of subscripts
and superscripts, attached to one base expression. It supports both
postscripts (to the right of the base in visual notation) and
prescripts (to the left of the base in visual notation). Missing
scripts can be represented by the empty element
<kw role="element">none</kw>.</p>
<p>The prescripts are optional, and when present are given
<emph>after</emph> the postscripts, because prescripts are relatively
rare compared to tensor notation.</p>
<p>The argument sequence consists of the base followed by zero or more
pairs of vertically-aligned subscripts and superscripts (in that
order) that represent all of the postscripts. This list is optionally
followed by an empty element <kw role="element">mprescripts</kw> and a
list of zero or more pairs of vertically-aligned presubscripts and
presuperscripts that represent all of the prescripts. The pair lists
for postscripts and prescripts are given in a left-to-right order. If
no subscript or superscript should be rendered in a given position,
then the empty element <kw role="element">none</kw> should be used in
that position.</p>
<p>The base, subscripts, superscripts, the optional separator element
<kw role="element">mprescripts</kw>, the presubscripts, and the
presuperscripts, are all direct sub-expressions of the
<kw role="element">mmultiscripts</kw> element, i.e. they are all at the
same level of the expression tree. Whether a script argument is a
subscript or a superscript, or whether it is a presubscript or a
presuperscript is determined by whether it occurs in an even-numbered
or odd-numbered argument position, respectively, ignoring the empty
element <kw role="element">mprescripts</kw> itself when determining the
position. The first argument, the base, is considered to be in
position 1. The total number of arguments must be odd, if
<kw role="element">mprescripts</kw> is not given, or even, if it is.</p>
<p>The empty elements <kw role="element">mprescripts</kw> and
<kw role="element">none</kw> are only allowed as direct sub-expressions
of <kw role="element">mmultiscripts</kw>.</p>
</div4>
<div4><head>Attributes</head>
<p>Same as the attributes of <kw role="element">msubsup</kw>.</p>
<p>The <kw role="element">mmultiscripts</kw> element increments <kw
role="attrib">scriptlevel</kw> by 1, and sets <kw
role="attrib">displaystyle</kw> to <kw role="attval">false</kw>, within
each of its arguments except <emph>base</emph>, but leaves both attributes
unchanged within <emph>base</emph>. (These attributes are inherited by
every element through its rendering environment, but can be set explicitly
only on <kw role="element">mstyle</kw>; see <specref ref="presm_mstyle"/>.)
</p>
</div4>
<div4><head>Examples</head>
<p>Two examples of the use of <kw role="element">mmultiscripts</kw> are:</p>
<p><sub>0</sub><mi>F</mi><sub>1</sub>(;<mi>a</mi>;<mi>z</mi>).
<eg role='mathml'><![CDATA[
<mrow>
<mmultiscripts>
<mi> F </mi>
<mn> 1 </mn>
<none/>
<mprescripts/>
<mn> 0 </mn>
<none/>
</mmultiscripts>
<mo> ⁡ </mo>
<mrow>
<mo> ( </mo>
<mrow>
<mo> ; </mo>
<mi> a </mi>
<mo> ; </mo>
<mi> z </mi>
</mrow>
<mo> ) </mo>
</mrow>
</mrow>
]]></eg>
</p>
<p><graphic role="inline" source="image/f3024.gif" alt="R_i{}^j_{kl}"/>
(where <mi>k</mi> and <mi>l</mi> are different indices)
<eg role='mathml'><![CDATA[
<mmultiscripts>
<mi> R </mi>
<mi> i </mi>
<none/>
<none/>
<mi> j </mi>
<mi> k </mi>
<none/>
<mi> l </mi>
<none/>
</mmultiscripts>
]]></eg>
</p>
</div4>
</div3>
</div2>
<div2 id="presm_tabmat"><head>Tables and Matrices</head>
<p>Matrices, arrays and other table-like mathematical notation are marked
up using <kw role="element">mtable</kw>,
<kw role="element">mtr</kw>, <kw role="element">mlabeledtr</kw> and
<kw role="element">mtd</kw> elements. These elements are similar to the
<kw role="element">TABLE</kw>, <kw role="element">TR</kw> and <kw
role="element">TD</kw> elements of HTML, except that they provide
specialized attributes for the fine layout control
necessary for commutative diagrams, block matrices and so on.</p>
<p>The <kw role="element">mlabeledtr</kw> element represents a labeled
row of a table and can be used for numbered equations.
The first child of <kw role="element">mlabeledtr</kw> is the label.
A label is somewhat special in that it is not considered an expression
in the matrix and is not counted when determining the number of columns
in that row.</p>
<div3 id="presm_mtable"><head>Table or Matrix
(<kw role="element">mtable</kw>)</head>
<div4><head>Description</head>
<p>A matrix or table is specified using the <kw
role="element">mtable</kw> element. Inside of the <kw
role="element">mtable</kw> element, only <kw role="element">mtr</kw>
or <kw role="element">mlabeledtr</kw> elements may appear.</p>
<p>In MathML 1.x, the <kw role="element">mtable</kw> element could
infer <kw role="element">mtr</kw> elements around its arguments, and
the <kw role="element">mtr</kw> element could infer <kw
role="element">mtd</kw> elements. In other words, if some argument to
an <kw role="element">mtable</kw> was not an <kw
role="element">mtr</kw> element, a MathML application was to assume a
row with a single column (i.e. the argument was effectively wrapped
with an inferred <kw role="element">mtr</kw>). Similarly, if some
argument to a (possibly inferred) <kw role="element">mtr</kw> element
was not an <kw role="element">mtd</kw> element, that argument was to
be treated as a table entry by wrapping it with an inferred <kw
role="element">mtd</kw> element.
MathML 2.0 <intref ref="interf_deprec">deprecates</intref> the inference
of <kw role="element">mtr</kw> and <kw role="element">mtd</kw> elements;
<kw role="element">mtr</kw> and <kw role="element">mtd</kw> elements
must be used inside of <kw role="element">mtable</kw> and
<kw role="element">mtr</kw> respectively.</p>
<p>Table rows that have fewer columns than other rows of the same
table (whether the other rows precede or follow them) are effectively
padded on the right with empty <kw role="element">mtd</kw> elements so
that the number of columns in each row equals the maximum number of
columns in any row of the table. Note that the use of
<kw role="element">mtd</kw> elements with non-default values of the
<kw role="attrib">rowspan</kw> or <kw role="attrib">columnspan</kw>
attributes may affect
the number of <kw role="element">mtd</kw> elements that should be given
in subsequent <kw role="element">mtr</kw> elements to cover a given
number of columns.
Note also that the label in an <kw role="element">mlabeledtr</kw> element
is not considered a column in the table.</p>
</div4>
<div4><head>Attributes</head>
<p>In addition to the attributes listed below, this element permits
<kw role="attrib">id</kw>,
<kw role="attrib">xref</kw>, <kw role="attrib">class</kw> and
<kw role="attrib">style</kw> attributes,
as described in <specref ref="fund_globatt"/>.</p>
<table border="1">
<thead>
<tr>
<td>Name</td>
<td>values</td>
<td>default</td>
</tr>
</thead>
<tbody>
<tr>
<td>align</td>
<td>(top | bottom | center | baseline | axis) [ rownumber ]</td>
<td>axis</td>
</tr>
<tr>
<td>rowalign</td>
<td>(top | bottom | center | baseline | axis) +</td>
<td>baseline</td>
</tr>
<tr>
<td>columnalign</td>
<td>(left | center | right) +</td>
<td>center</td>
</tr>
<tr>
<td>groupalign</td>
<td>group-alignment-list-list</td>
<td>{left}</td>
</tr>
<tr>
<td>alignmentscope</td>
<td>(true | false) +</td>
<td>true</td>
</tr>
<tr>
<td>columnwidth</td>
<td>( auto | number h-unit | namedspace | fit ) +</td>
<td>auto</td>
</tr>
<tr>
<td>width</td>
<td>auto | number h-unit</td>
<td>auto</td>
</tr>
<tr>
<td>rowspacing</td>
<td>( number v-unit ) +</td>
<td>1.0ex</td>
</tr>
<tr>
<td>columnspacing</td>
<td>( number h-unit | namedspace ) +</td>
<td>0.8em</td>
</tr>
<tr>
<td>rowlines</td>
<td>(none | solid | dashed) +</td>
<td>none</td>
</tr>
<tr>
<td>columnlines</td>
<td>(none | solid | dashed) +</td>
<td>none</td>
</tr>
<tr>
<td>frame</td>
<td>none | solid | dashed</td>
<td>none</td>
</tr>
<tr>
<td>framespacing</td>
<td>(number h-unit | namedspace) (number v-unit | namedspace)</td>
<td>0.4em 0.5ex</td>
</tr>
<tr>
<td>equalrows</td>
<td>true | false</td>
<td>false</td>
</tr>
<tr>
<td>equalcolumns</td>
<td>true | false</td>
<td>false</td>
</tr>
<tr>
<td>displaystyle</td>
<td>true | false</td>
<td>false</td>
</tr>
<tr>
<td>side</td>
<td>left | right | leftoverlap | rightoverlap</td>
<td>right</td>
</tr>
<tr>
<td>minlabelspacing</td>
<td>number h-unit</td>
<td>0.8em</td>
</tr>
</tbody>
</table>
<p>Note that the default value for each of <kw
role="attrib">rowlines</kw>, <kw role="attrib">columnlines</kw> and
<kw role="attrib">frame</kw> is the literal string
<quote>none</quote>, meaning that the default is to render no lines,
rather than that there is no default.</p>
<p>As described in <specref ref="fund_attval"/>, the notation <code>(x
| y)+</code> means one or more occurrences of either <code>x</code> or
<code>y</code>, separated by whitespace. For example, possible values
for <kw role="attrib">columnalign</kw> are <kw
role="attval">left</kw>, <kw role="attval">left left</kw>, and <kw
role="attval">left right center center</kw>. If there are more
entries than are necessary (e.g. more entries than columns for <kw
role="attrib">columnalign</kw>), then only the first entries will be
used. If there are fewer entries, then the last entry is repeated as
often as necessary. For example, if <kw
role="attrib">columnalign</kw>="right center" and the table has three
columns, the first column will be right aligned and the second and
third columns will be centered. The label in a <kw
role="element">mlabeledtr</kw> is not considered as a column in the
table and the attribute values that apply to columns do not apply to
labels.</p>
<p>The <kw role="attrib">align</kw> attribute specifies where to align the
table with respect to its environment. <kw role="attval">axis</kw> means to align
the center of the table on the environment's axis. (The axis of an equation
is an alignment line used by typesetters. It is the line on which a minus
sign typically lies. The center of the table is the midpoint of the
table's vertical extent.) <kw role="attval">center</kw> and <kw role="attval">baseline</kw>
both mean to align the center of the table on the environment's
baseline. <kw role="attval">top</kw> or <kw role="attval">bottom</kw> aligns the top or
bottom of the table on the environment's baseline.</p>
<p>If the <kw role="attrib">align</kw> attribute value ends with a
<kw role="attval">rownumber</kw> between 1 and <mi>n</mi> (for a table with
<mi>n</mi> rows), the specified row is aligned in the way described above,
rather than the table as a whole; the top (first) row is numbered 1, and
the bottom (last) row is numbered <mi>n</mi>. The same is true if the
row number is negative, between -1 and -<mi>n</mi>,
except that the bottom row is referred to as -1 and the top row as
-<mi>n</mi>. Other values of <kw role="attval">rownumber</kw> are
illegal.</p>
<p>The <kw role="attrib">rowalign</kw> attribute specifies how the entries in
each row should be aligned. For example, <kw role="attval">top</kw> means that the tops of
each entry in each row should be aligned with the tops of the other
entries in that row. The <kw role="attrib">columnalign</kw> attribute specifies
how the entries in each column should be aligned.</p>
<p>The <kw role="attrib">groupalign</kw> and <kw role="attrib">alignmentscope</kw>
attributes are described with the alignment elements,
<kw role="element">maligngroup</kw> and
<kw role="element">malignmark</kw>, in <specref
ref="presm_malign"/>.</p>
<p>The <kw role="attrib">columnwidth</kw> attribute specifies how wide
a column should be. The <kw role="attval">auto</kw> value means that
the column should be as wide as needed, which is the default. If an
explicit value is given, then the column is exactly that wide and the
contents of that column are made to fit in that width. The contents
are linewrapped or clipped at the discretion of the renderer. If <kw
role="attval">fit</kw> is given as a value, the remaining page width
after subtracting the widths for columns specified as <kw
role="attval">auto</kw> and/or specific widths is divided equally
among the <kw role="attval">fit</kw> columns and this value is used
for the column width. If insufficient room remains to hold the
contents of the <kw role="attval">fit</kw> columns, renderers may
linewrap or clip the contents of the <kw role="attval">fit</kw>
columns. When the <kw role="attrib">columnwidth</kw> is specified as
a percentage, the value is relative to the width of the table. That
is, a renderer should try to adjust the width of the column so that it
covers the specified percentage of the entire table width.</p>
<p>The <kw role="attrib">width</kw> attribute specifies the desired
width of the entire table and is intended for visual user agents. When
the value is a percentage value, the value is relative to the
horizontal space a MathML renderer has available for the table
element. When the value is <kw role="attval">auto</kw>, the MathML
renderer should calculate the table width from its contents using
whatever layout algorithm it chooses.</p>
<p>MathML 2.0 does not specify a table layout algorithm. In
particular, it is the responsibility of a MathML renderer to resolve
conflicts between the <kw role="attrib">width</kw> attribute and other
constraints on the width of a table, such as explicit values for <kw
role="attrib">columnwidth</kw> attributes, and minimum sizes for table
cell contents. For a discussion of table layout algorithms, see
<loc
href="http://www.w3.org/TR/CSS2/tables.html#width-layout">Cascading
Style Sheets, level 2</loc>.</p>
<p>The <kw role="attrib">rowspacing</kw> and <kw role="attrib">columnspacing</kw>
attributes specify how much space should be added between each row and
column. However, spacing before the first row and after the last row
(i.e. at the top and bottom of the table) is given by the second
number in the value of the <kw role="attrib">framespacing</kw> attribute, and
spacing before the first column and after the last column (i.e. on the
left and on the right of the table) is given by the first number in
the value of the <kw role="attrib">framespacing</kw> attribute.</p>
<p>In those attributes' syntaxes, <emph>h-unit</emph> or
<emph>v-unit</emph> represents a unit of horizontal or vertical
length, respectively (see <specref ref="fund_units"/>). The units shown in the
attributes' default values (<code>em</code> or <code>ex</code>) are
typically used.</p>
<p>The <kw role="attrib">rowlines</kw> and <kw role="attrib">columnlines</kw> attributes
specify whether and what kind of lines should be added between each
row and column. Lines before the first row or column and after the
last row or column are given using the <kw role="attrib">frame</kw>
attribute.</p>
<p>If a frame is desired around the table, the <kw role="attrib">frame</kw>
attribute is used. If the attribute value is not <quote>none</quote>, then
<kw role="attrib">framespacing</kw> is used to add spacing between the lines of
the frame and the first and last rows and columns of the table. If
<kw role="attrib">frame</kw>="none", then the <kw role="attrib">framespacing</kw>
attribute is ignored. The <kw role="attrib">frame</kw> and
<kw role="attrib">framespacing</kw> attributes are not part of the
<kw role="attrib">rowlines</kw>/<kw role="attrib">columnlines</kw>,
<kw role="attrib">rowspacing</kw>/<kw role="attrib">columnspacing</kw> options because
having them be so would often require that <kw role="attrib">rowlines</kw> and
<kw role="attrib">columnlines</kw> would need to be fully specified instead of
just giving a single value.
For example, if a table had five columns and it was desired to have
no frame around the table but to have lines between the columns, then
<code>columnlines="none solid solid solid solid none"</code>
would be necessary. If the frame is separated from the internal
lines, only <code>columnlines="solid"</code> is needed.</p>
<p>The <kw role="attrib">equalrows</kw> attribute forces the rows all to be
the same total height when set to <kw role="attval">true</kw>. The <kw
role="attrib">equalcolumns</kw> attribute forces the columns all to be the
same width when set to <kw role="attval">true</kw>.</p>
<p>The <kw role="attrib">displaystyle</kw> attribute specifies the
value of <kw role="attrib">displaystyle</kw> (described under <kw
role="element">mstyle</kw> in <specref ref="presm_mstyle"/>) within
each cell (<kw role="element">mtd</kw> element) of the table. Setting
<kw role="attrib">displaystyle</kw>=<kw role="attval">true</kw> can be
useful for tables whose elements are whole mathematical expressions;
the default value of <kw role="attval">false</kw> is appropriate when
the table is part of an expression, for example, when it represents a
matrix. In either case, <kw role="attrib">scriptlevel</kw> (<specref
ref="presm_mstyle"/>) is not changed for the table cells.</p>
<p>The <kw role="attrib">side</kw> attribute
specifies what side of a table a label for a table row should should be
placed. This attribute is intended to be used for labeled expressions.
If <kw role="attval">left</kw> or <kw role="attval">right</kw> is specified,
the label is placed on the left or right side of the table row respectively.
The other two attribute values are variations on
<kw role="attval">left</kw> and <kw role="attval">right</kw>:
if the labeled row fits within the width allowed for the table without
the label,
but does not fit within the width if the label is included, then the
label overlaps the row and is displayed above the row if
<kw role="attrib">rowalign</kw> for that row is <kw role="attval">top</kw>;
otherwise the label is displayed below the row.</p>
<p>
If there are multiple labels in a table, the alignment of the labels within
the virtual column that they form is left-aligned for labels on the left
side of the table, and right-aligned for labels on the right side of the
table. The alignment can be overridden by specifying
<kw role="attrib">columnalignment</kw> for a <kw role="element">mlabeledtr</kw>
element.
</p>
<p>The <kw role="attrib">minlabelspacing</kw> attribute
specifies the minimum space allowed between a label and the adjacent
entry in the row.
</p>
</div4>
<div4><head>Examples</head>
<p>A 3 by 3 identity matrix could be represented as follows:
<eg role='mathml'><![CDATA[
<mrow>
<mo> ( </mo>
<mtable>
<mtr>
<mtd> <mn>1</mn> </mtd>
<mtd> <mn>0</mn> </mtd>
<mtd> <mn>0</mn> </mtd>
</mtr>
<mtr>
<mtd> <mn>0</mn> </mtd>
<mtd> <mn>1</mn> </mtd>
<mtd> <mn>0</mn> </mtd>
</mtr>
<mtr>
<mtd> <mn>0</mn> </mtd>
<mtd> <mn>0</mn> </mtd>
<mtd> <mn>1</mn> </mtd>
</mtr>
</mtable>
<mo> ) </mo>
</mrow>
]]></eg>
</p>
<p>This might be rendered as:
<graphic source="image/f3025.gif"
alt="\left(\begin{array}{ccc}1 & 0 & 0 \\ 0 & 1 & 0 \\ 0 & 0 & 1\end{array}\right)"/>
Note that the parentheses must be represented explicitly; they are not
part of the <kw role="element">mtable</kw> element's rendering. This allows
use of other surrounding fences, such as brackets, or none at all.</p>
</div4>
</div3>
<div3 id="presm_mtr"><head>Row in Table or Matrix (<kw role="element">mtr</kw>)</head>
<div4><head>Description</head>
<p>An <kw role="element">mtr</kw> element represents one row in a table
or matrix. An <kw role="element">mtr</kw> element is only allowed as a
direct sub-expression of an <kw role="element">mtable</kw> element, and
specifies that its contents should form one row of the table. Each
argument of <kw role="element">mtr</kw> is placed in a different column
of the table, starting at the leftmost column.</p>
<p>As described in <specref ref="presm_mtable"/>,
<kw role="element">mtr</kw> elements are
effectively padded on the right with <kw role="element">mtd</kw>
elements when they are shorter than other rows in a table.
</p>
</div4>
<div4><head>Attributes</head>
<p>In addition to the attributes listed below, this element permits
<kw role="attrib">id</kw>,
<kw role="attrib">xref</kw>, <kw role="attrib">class</kw> and
<kw role="attrib">style</kw> attributes,
as described in <specref ref="fund_globatt"/>.</p>
<table border="1">
<thead>
<tr>
<td>Name</td>
<td>values</td>
<td>default</td>
</tr>
</thead>
<tbody>
<tr>
<td>rowalign</td>
<td>top | bottom | center | baseline | axis</td>
<td>inherited</td>
</tr>
<tr>
<td>columnalign</td>
<td>(left | center | right) +</td>
<td>inherited</td>
</tr>
<tr>
<td>groupalign</td>
<td>group-alignment-list-list</td>
<td>inherited</td>
</tr>
</tbody>
</table>
<p>The <kw role="attrib">rowalign</kw> and <kw
role="attrib">columnalign</kw> attributes allow a specific row to
override the alignment specified by the same attributes in the
surrounding <kw role="element">mtable</kw> element.</p>
<p>As with <kw role="element">mtable</kw>, if there are more entries than
necessary in the value of <kw role="attrib">columnalign</kw> (i.e. more entries
than columns in the row), then the extra entries will be ignored. If
there are fewer entries than columns, then the last entry will be
repeated as many times as needed.</p>
<p>The <kw role="attrib">groupalign</kw> attribute is described with the alignment
elements, <kw role="element">maligngroup</kw> and <kw role="element">malignmark</kw>,
in <specref ref="presm_malign"/>.</p>
</div4>
</div3>
<div3 id="presm_mlabeledtr"><head>Labeled Row in Table or Matrix
(<kw role="element">mlabeledtr</kw>)</head>
<div4><head>Description</head>
<p>An <kw role="element">mlabeledtr</kw> element represents one row in
a table that has a label on either the left or right side, as
determined by the <kw role="attrib">side</kw> attribute. The label is
the first child of <kw role="element">mlabeledtr</kw>. The rest of
the children represent the contents of the row and are identical to
those used for <kw role="element">mtr</kw>; all of the children except
the first must be <kw role="element">mtd</kw> elements.
</p>
<p>
An <kw role="element">mlabeledtr</kw> element is only allowed as a
direct sub-expression of an <kw role="element">mtable</kw> element.
Each argument of <kw role="element">mlabeledtr</kw> except for the first
argument (the label) is placed in a different column
of the table, starting at the leftmost column.</p>
<p>Note that the label element is not considered to be a cell in the
table row. In particular, the label element is not taken into
consideration in the table layout for purposes of width and alignment
calculations. For example, in the case of an <kw
role="element">mlabeledtr</kw> with a label and a single centered <kw
role="element">mtd</kw> child, the child is first centered in the
enclosing <kw role="element">mtable</kw>, and then the label is
placed. Specifically, the child is <emph>not</emph> centered in the
space that remains in the table after placing the label.</p>
<p>While MathML 2.0 does not specify an algorithm for placing labels,
implementors of visual renderers may find the following formatting
model useful. To place a label, an implementor might think in terms
of creating a larger table, with an extra column on both ends. The
<kw role="attrib">columnwidth</kw> attributes of both these border
columns would be set to <kw role="attval">fit</kw> so that they expand
to fill whatever space remains after the inner columns have been laid
out. Finally, depending on the values of <kw role="attrib">side</kw>
and <kw role="attrib">minlabelspacing</kw>, the label is placed
in whatever border column is appropriate, possibly shifted down if
necessary.</p>
</div4>
<div4><head>Attributes</head>
<p>
The attributes for <kw role="element">mlabeledtr</kw> are the same
as for <kw role="element">mtr</kw>. Unlike the attributes for the
<kw role="element">mtable</kw> element, attributes of
<kw role="element">mlabeledtr</kw> that apply to column elements
also apply to the label. For example, in a one column table,
<eg role="mathml-fragment">
<![CDATA[
<mlabeledtr rowalign='top'>
]]>
</eg>
means that the label and other entries in the row are vertically aligned
along their top. To force a particular alignment on the label,
the appropriate attribute would normally be set on the
<kw role="element">mtd</kw> start tag that surrounds the label content.
</p>
</div4>
<div4><head>Equation Numbering</head>
<p>One of the important uses of <kw role="element">mlabeledtr</kw> is
for numbered equations. In a <kw role="element">mlabeledtr</kw>, the
label represents the equation number and the elements in the row are
the equation being numbered. The <kw role="attrib">side</kw> and <kw
role="attrib">minlabelspacing</kw> attributes of <kw
role="element">mtable</kw> determine the placement of the equation
number.</p>
<p>In larger documents with many numbered equations, automatic
numbering becomes important. While automatic equation numbering and
automatically resolving references to equation numbers is outside the
scope of MathML, these problems can be addressed by the use of style
sheets or other means. The mlabeledtr construction provides support
for both of these functions in a way that is intended to facilitate
XSLT processing. The <kw role="element">mlabeledtr</kw> element can be
used to indicate the presence of a numbered equation, and the first
child can be changed to the current equation number, along with
incrementing the global equation number. For cross references, an
id on either the mlabeledtr element or on the first element
itself could be used as a target of any link.</p>
<eg role='mathml'><![CDATA[
<mtable>
<mlabeledtr id='e-is-m-c-square'>
<mtd>
<mtext> (2.1) </mtext>
</mtd>
<mtd>
<mrow>
<mi>E</mi>
<mo>=</mo>
<mrow>
<mi>m</mi>
<mo>⁢</mo>
<msup>
<mi>c</mi>
<mn>2</mn>
</msup>
</mrow>
</mrow>
</mtd>
</mlabeledtr>
</mtable>
]]></eg>
<p>This should be rendered as:
<table width="100%">
<tbody>
<tr>
<td id="eqnoc1"> </td>
<td id="eqnoc2"><mi>E</mi> = <mi>m</mi><mi>c</mi><sup>2</sup></td>
<td id="eqnoc3">(2.1)</td>
</tr>
</tbody>
</table>
</p>
</div4>
</div3>
<div3 id="presm_mtd"><head>Entry in Table or Matrix (<kw role="element">mtd</kw>)</head>
<div4><head>Description</head>
<p>An <kw role="element">mtd</kw> element represents one entry, or cell, in a
table or matrix. An <kw role="element">mtd</kw> element is only
allowed as a direct sub-expression of an <kw role="element">mtr</kw>
or an <kw role="element">mlabeledtr</kw> element.</p>
<p>The <kw role="element">mtd</kw> element accepts any number of
arguments; if this number is not 1, its contents are treated as a single
<quote>inferred <kw role="element">mrow</kw></quote> formed from all its
arguments, as described in <specref ref="presm_reqarg"/>.</p>
</div4>
<div4 id="presm_mtdatts"><head>Attributes</head>
<table border="1">
<thead>
<tr>
<td>Name</td>
<td>values</td>
<td>default</td>
</tr>
</thead>
<tbody>
<tr>
<td>rowspan</td>
<td>number</td>
<td>1</td>
</tr>
<tr>
<td>columnspan</td>
<td>number</td>
<td>1</td>
</tr>
<tr>
<td>rowalign</td>
<td>top | bottom | center | baseline | axis</td>
<td>inherited</td>
</tr>
<tr>
<td>columnalign</td>
<td>left | center | right</td>
<td>inherited</td>
</tr>
<tr>
<td>groupalign</td>
<td>group-alignment-list</td>
<td>inherited</td>
</tr>
</tbody>
</table>
<p>The <kw role="attrib">rowspan</kw> and <kw role="attrib">columnspan</kw> attributes
allow a specific matrix element to be treated as if it occupied the
number of rows or columns specified. The interpretation of how this
larger element affects specifying subsequent rows and columns is meant
to correspond with the similar attributes for HTML 4.01 tables.</p>
<p>The <kw role="attrib">rowspan</kw> and <kw role="attrib">columnspan</kw> attributes
can be used around an <kw role="element">mtd</kw> element that represents
the label in a <kw role="element">mlabeledtr</kw> element.
Also, the label of a <kw role="element">mlabeledtr</kw> element is not
considered to be part of a previous <kw role="attrib">rowspan</kw> and
<kw role="attrib">columnspan</kw>.
</p>
<p>The <kw role="attrib">rowalign</kw> and <kw role="attrib">columnalign</kw> attributes
allow a specific matrix element to override the alignment specified by
a surrounding <kw role="element">mtable</kw> or <kw role="element">mtr</kw>
element.</p>
<p>The <kw role="attrib">groupalign</kw> attribute is described with the alignment
elements, <kw role="element">maligngroup</kw> and <kw role="element">malignmark</kw>,
in <specref ref="presm_malign"/>.</p>
</div4>
</div3>
<div3 id="presm_malign"><head>Alignment Markers</head>
<div4><head>Description</head>
<p>Alignment markers are space-like elements (see <specref
ref="presm_mspace"/>) that can be used
to vertically align specified points within a column of MathML
expressions by the automatic insertion of the necessary amount of
horizontal space between specified sub-expressions.</p>
<p>The discussion that follows will use the example of a set of
simultaneous equations that should be rendered with vertical
alignment of the coefficients and variables of each term, by
inserting spacing somewhat like that shown here:
<eg><![CDATA[
8.44x + 55 y = 0
3.1 x - 0.7y = -1.1
]]></eg>
If the example expressions shown above were arranged in a column
but not aligned, they would appear as:
<eg><![CDATA[
8.44x + 55y = 0
3.1x - 0.7y = -1.1
]]></eg>
(For audio renderers, it is suggested that the alignment elements
produce the analogous behavior of altering the rhythm of pronunciation
so that it is the same for several sub-expressions in a column, by the
insertion of the appropriate time delays in place of the extra
horizontal spacing described here.)</p>
<p>The expressions whose parts are to be aligned (each equation, in the
example above) must be given as the table elements (i.e. as the <kw
role="element">mtd</kw> elements) of one column of an
<kw role="element">mtable</kw>. To avoid confusion, the term <quote>table
cell</quote> rather than <quote>table element</quote> will be used in the
remainder of this section.</p>
<p>All interactions between alignment elements are limited to the
<kw role="element">mtable</kw> column they arise in. That is, every
column of a table specified by an <kw role="element">mtable</kw> element
acts as an <quote>alignment scope</quote> that contains within it all alignment
effects arising from its contents. It also excludes any interaction
between its own alignment elements and the alignment elements inside
any nested alignment scopes it might contain.</p>
<p>The reason <kw role="element">mtable</kw> columns are used as
alignment scopes is that they are the only general way in MathML to
arrange expressions into vertical columns. Future versions of MathML
may provide an <kw role="element">malignscope</kw> element that allows
an alignment scope to be created around any MathML element, but even
then, table columns would still sometimes need to act as alignment
scopes, and since they are not elements themselves, but rather are
made from corresponding parts of the content of several
<kw role="element">mtr</kw> elements, they could not individually be the
content of an alignment scope element.</p>
<p>An <kw role="element">mtable</kw> element can be given the attribute
<kw role="attrib">alignmentscope</kw>=<kw role="attval">false</kw> to cause
its columns not to act as alignment scopes. This is discussed further at
the end of this section. Otherwise, the discussion in this section assumes
that this attribute has its default value of <kw
role="attval">true</kw>.</p>
</div4>
<div4><head>Specifying alignment groups</head>
<p>To cause alignment, it is necessary to specify, within each
expression to be aligned, the points to be aligned with corresponding
points in other expressions, and the beginning of each <emph>alignment
group</emph> of sub-expressions that can be horizontally shifted as a
unit to effect the alignment. Each alignment group must contain one
alignment point. It is also necessary to specify which expressions in
the column have no alignment groups at all, but are affected only by
the ordinary column alignment for that column of the table, i.e. by
the <kw role="attrib">columnalign</kw> attribute, described elsewhere.</p>
<p>The alignment groups start at the locations of invisible
<kw role="element">maligngroup</kw> elements, which are rendered with
zero width when they occur outside of an alignment scope, but within
an alignment scope are rendered with just enough horizontal space to
cause the desired alignment of the alignment group that follows
them. A simple algorithm by which a MathML application can achieve this is given
later. In the example above, each equation would have one
<kw role="element">maligngroup</kw> element before each coefficient,
variable, and operator on the left-hand side, one before the
<code>=</code> sign, and one before the constant on the right-hand
side.</p>
<p>In general, a table cell containing <mi>n</mi>
<kw role="element">maligngroup</kw> elements contains <mi>n</mi>
alignment groups, with the <mi>i</mi>th group consisting of the
elements entirely after the <mi>i</mi>th
<kw role="element">maligngroup</kw> element and before the
(<mi>i</mi>+1)-th; no element within the table cell's content
should occur entirely before its first
<kw role="element">maligngroup</kw> element.</p>
<p>Note that the division into alignment groups does <emph>not</emph>
necessarily fit the nested expression structure of the MathML
expression containing the groups – that is, it is permissible for one
alignment group to consist of the end of one
<kw role="element">mrow</kw>, all of another one, and the beginning of a
third one, for example. This can be seen in the MathML markup for the
present example, given at the end of this section.</p>
<p>The nested expression structure formed by <kw role="element">mrow</kw>s
and other layout schemata should reflect the mathematical structure of the
expression, not the alignment-group structure, to make possible optimal
renderings and better automatic interpretations; see the discussion of
proper grouping in section <specref ref="presm_mrow"/>. Insertion of
alignment elements (or other space-like elements) should not alter the
correspondence between the structure of a MathML expression and the
structure of the mathematical expression it represents.</p>
<p>Although alignment groups need to coincide with the nested
expression structure of layout schemata, there are nonetheless
restrictions on where an <kw role="element">maligngroup</kw> element is
allowed within a table cell. The <kw role="element">maligngroup</kw>
element may only be contained within elements of the following types
(which are themselves contained in the table cell):
<ulist>
<item><p>an <kw role="element">mrow</kw> element, including an inferred
<kw role="element">mrow</kw> such as the one formed by a multi-argument
<kw role="element">mtd</kw> element;</p>
</item>
<item><p>an <kw role="element">mstyle</kw> element;</p>
</item>
<item><p>an <kw role="element">mphantom</kw> element;</p>
</item>
<item><p>an <kw role="element">mfenced</kw> element;</p>
</item>
<item><p>an <kw role="element">maction</kw> element, though only its
selected sub-expression is checked;</p>
</item>
<item><p>a <kw role="element">semantics</kw> element.</p>
</item>
</ulist>
</p>
<p>These restrictions are intended to ensure that alignment can be
unambiguously specified, while avoiding complexities involving things
like overscripts, radical signs and fraction bars. They also ensure
that a simple algorithm suffices to accomplish the desired
alignment.</p>
<p>Note that some positions for an <kw role="element">maligngroup</kw>
element, although legal, are not useful, such as for an
<kw role="element">maligngroup</kw> element to be an argument of an
<kw role="element">mfenced</kw> element. When inserting an
<kw role="element">maligngroup</kw> element before a given element in
pre-existing MathML, it will often be necessary, and always
acceptable, to form a new <kw role="element">mrow</kw> element to contain
just the <kw role="element">maligngroup</kw> element and the element it
is inserted before. In general, this will be necessary except when the
<kw role="element">maligngroup</kw> element is inserted directly into an
<kw role="element">mrow</kw> or into an element that can form an
inferred <kw role="element">mrow</kw> from its contents. See the warning
about the legal grouping of <quote>space-like elements</quote> in
<specref ref="presm_mspace"/>.</p>
<p>For the table cells that are divided into alignment groups, every
element in their content must be part of exactly one alignment group,
except the elements from the above list that contain
<kw role="element">maligngroup</kw> elements inside them, and the
<kw role="element">maligngroup</kw> elements themselves. This means
that, within any table cell containing alignment groups, the first
complete element must be an <kw role="element">maligngroup</kw> element,
though this may be preceded by the start tags of other elements.</p>
<p>This requirement removes a potential confusion about how to align
elements before the first <kw role="element">maligngroup</kw> element,
and makes it easy to identify table cells that are left out of their
column's alignment process entirely.</p>
<p>Note that it is not required that the table cells in a column that
are divided into alignment groups each contain the same number of
groups. If they don't, zero-width alignment groups are effectively
added on the right side of each table cell that has fewer groups than
other table cells in the same column.</p>
</div4>
<div4><head>Table cells that are not divided into alignment groups</head>
<p>Expressions in a column that are to have no alignment groups
should contain no <kw role="element">maligngroup</kw>
elements. Expressions with no alignment groups are aligned using only
the <kw role="attrib">columnalign</kw> attribute that applies to the table
column as a whole, and are not affected by the <kw role="attrib">groupalign</kw>
attribute described below. If such an expression is wider than the
column width needed for the table cells containing alignment groups,
all the table cells containing alignment groups will be shifted as a
unit within the column as described by the <kw role="attrib">columnalign</kw>
attribute for that column. For example, a column heading with no
internal alignment could be added to the column of two equations given
above by preceding them with another table row containing an
<kw role="element">mtext</kw> element for the heading, and using the
default <kw role="attrib">columnalign</kw>="center" for the table, to
produce:
<eg><![CDATA[
equations with aligned variables
8.44x + 55 y = 0
3.1 x - 0.7y = -1.1
]]></eg>
or, with a shorter heading,
<eg><![CDATA[
some equations
8.44x + 55 y = 0
3.1 x - 0.7y = -1.1
]]></eg>
</p>
</div4>
<div4><head>Specifying alignment points using <kw role="element">malignmark</kw></head>
<p>Each alignment group's alignment point can either be specified by
an <kw role="element">malignmark</kw> element anywhere within the
alignment group (except within another alignment scope wholly
contained inside it), or it is determined automatically from the
<kw role="attrib">groupalign</kw> attribute. The <kw role="attrib">groupalign</kw>
attribute can be specified on the group's preceding
<kw role="element">maligngroup</kw> element or on its surrounding
<kw role="element">mtd</kw>, <kw role="element">mtr</kw>, or
<kw role="element">mtable</kw> elements. In typical cases, using the
<kw role="attrib">groupalign</kw> attribute is sufficient to describe the
desired alignment points, so no <kw role="element">malignmark</kw>
elements need to be provided.</p>
<p>The <kw role="element">malignmark</kw> element indicates that the
alignment point should occur on the right edge of the preceding
element, or the left edge of the following element or character,
depending on the <kw role="attrib">edge</kw> attribute of
<kw role="element">malignmark</kw>. Note that it may be necessary to
introduce an <kw role="element">mrow</kw> to group an
<kw role="element">malignmark</kw> element with a neighboring element,
in order not to alter the argument count of the containing
element. (See the warning about the legal grouping of <quote>space-like
elements</quote> in <specref ref="presm_mspace"/>).</p>
<p>When an <kw role="element">malignmark</kw> element is provided within an
alignment group, it can occur in an arbitrarily deeply nested element
within the group, as long as it is not within a nested alignment scope. It
is not subject to the same restrictions on location as <kw
role="element">maligngroup</kw> elements. However, its immediate
surroundings need to be such that the element to its immediate right or
left (depending on its <kw role="attrib">edge</kw> attribute) can be
unambiguously identified. If no such element is present, renderers should
behave as if a zero-width element had been inserted there.</p>
<p>For the purposes of alignment, an element X is considered to be to the
immediate left of an element Y, and Y to the immediate right of X, whenever
X and Y are successive arguments of one (possibly inferred) <kw
role="element">mrow</kw> element, with X coming before Y. In the case of
<kw role="element">mfenced</kw> elements, MathML applications should evaluate this
relation as if the <kw role="element">mfenced</kw> element had been
replaced by the equivalent expanded form involving <kw
role="element">mrow</kw>. Similarly, an <kw role="element">maction</kw>
element should be treated as if it were replaced by its currently selected
sub-expression. In all other cases, no relation of <quote>to the immediate
left or right</quote> is defined for two elements X and Y. However, in the
case of content elements interspersed in presentation markup, MathML applications
should attempt to evaluate this relation in a sensible way. For example, if
a renderer maintains an internal presentation structure for rendering
content elements, the relation could be evaluated with respect to
that. (See <specref ref="contm"/> and <specref ref="mixing"/> for further
details about mixing presentation and content markup.)</p>
<p>Unlike all other elements in MathML,
<kw role="element">malignmark</kw> elements are allowed to occur within
the content of token elements, such as <kw role="element">mn</kw>,
<kw role="element">mi</kw>, or <kw role="element">mtext</kw>. When this
occurs, the character immediately before or after the
<kw role="element">malignmark</kw> element will carry the alignment
point; in all other cases, the element to its immediate left or right
will carry the alignment point. The rationale for this is that it is
sometimes desirable to align on the edges of specific characters
within multi-character token elements.</p>
<p>If there is more than one <kw role="element">malignmark</kw> element
in an alignment group, all but the first one will be ignored. MathML
applications may wish to provide a mode in which they will warn about
this situation, but it is not an error, and should trigger no warnings
by default. (Rationale: it would be inconvenient to have to remove all
unnecessary <kw role="element">malignmark</kw> elements from
automatically generated data, in certain cases, such as when they are
used to specify alignment on <quote>decimal points</quote> other than the '.'
character.)</p>
</div4>
<div4><head>Attributes</head>
<p>In addition to the attributes listed below, the <kw
role="element">malignmark</kw> element permits
<kw role="attrib">id</kw>,
<kw role="attrib">xref</kw>, <kw role="attrib">class</kw> and
<kw role="attrib">style</kw> attributes,
as described in <specref ref="fund_globatt"/>.</p>
<table border="1">
<thead>
<tr>
<td>Name</td>
<td>values</td>
<td>default</td>
</tr>
</thead>
<tbody>
<tr>
<td>edge</td>
<td>left | right</td>
<td>left</td>
</tr>
</tbody>
</table>
<p><kw role="element">malignmark</kw> has one attribute,
<kw role="attrib">edge</kw>, which specifies whether the alignment point will be
found on the left or right edge of some element or character. The
precise location meant by <quote>left edge</quote> or <quote>right edge</quote> is discussed
below. If <kw role="attrib">edge</kw>="right", the alignment point is the right
edge of the element or character to the immediate left of the
<kw role="element">malignmark</kw> element. If <kw role="attrib">edge</kw>="left",
the alignment point is the left edge of the element or character to
the immediate right of the <kw role="element">malignmark</kw>
element. Note that the attribute refers to the choice of edge rather
than to the direction in which to look for the element whose edge will
be used.</p>
<p>For <kw role="element">malignmark</kw> elements that occur within
the content of MathML token elements, the preceding or following
character in the token element's content is used; if there is no such
character, a zero-width character is effectively inserted for the
purpose of carrying the alignment point on its edge. For all other
<kw role="element">malignmark</kw> elements, the preceding or following
element is used; if there is no such element, a zero-width element is
effectively inserted to carry the alignment point.</p>
<p>The precise definition of the <quote>left edge</quote> or <quote>right edge</quote> of a
character or glyph (e.g. whether it should coincide with an edge of
the character's bounding box) is not specified by MathML, but is at
the discretion of the renderer; the renderer is allowed to let the
edge position depend on the character's context as well as on the
character itself.</p>
<p>For proper alignment of columns of numbers (using <kw
role="attrib">groupalign</kw> values of <kw role="attval">left</kw>, <kw
role="attval">right</kw>, or <kw role="attval">decimalpoint</kw>), it is
likely to be desirable for the effective width (i.e. the distance between
the left and right edges) of decimal digits to be constant, even if their
bounding box widths are not constant (e.g. if <quote>1</quote> is narrower
than other digits). For other characters, such as letters and operators, it
may be desirable for the aligned edges to coincide with the bounding
box.</p>
<p>The <quote>left edge</quote> of a MathML element or alignment group
refers to the left edge of the leftmost glyph drawn to render the element
or group, except that explicit space represented by <kw
role="element">mspace</kw> or <kw role="element">mtext</kw> elements
should also count as <quote>glyphs</quote> in this context, as should
glyphs that would be drawn if not for <kw role="element">mphantom</kw>
elements around them. The <quote>right edge</quote> of an element or
alignment group is defined similarly.</p>
</div4>
<div4><head>Attributes</head>
<p>In addition to the attributes listed below, the <kw
role="element">malignmark</kw> element permits
<kw role="attrib">id</kw>,
<kw role="attrib">xref</kw>, <kw role="attrib">class</kw> and
<kw role="attrib">style</kw> attributes,
as described in <specref ref="fund_globatt"/>.</p>
<table border="1">
<thead>
<tr>
<td>Name</td>
<td>values</td>
<td>default</td>
</tr>
</thead>
<tbody>
<tr>
<td>groupalign</td>
<td>left | center | right | decimalpoint</td>
<td>inherited</td>
</tr>
</tbody>
</table>
<p><kw role="element">maligngroup</kw> has one attribute,
<kw role="attrib">groupalign</kw>, which is used to determine the position of
its group's alignment point when no <kw role="element">malignmark</kw>
element is present. The following discussion assumes that no
<kw role="element">malignmark</kw> element is found within a group.</p>
<p>In the example given at the beginning of this section, there is one
column of 2 table cells, with 7 alignment groups in each table cell;
thus there are 7 columns of alignment groups, with 2 groups, one above
the other, in each column. These columns of alignment groups should be
given the 7 <kw role="attrib">groupalign</kw> values <quote>decimalpoint left left
decimalpoint left left decimalpoint</quote>, in that order. How to specify
this list of values for a table cell or table column as a whole, using
attributes on elements surrounding the
<kw role="element">maligngroup</kw> element is described later.</p>
<p>If <kw role="attrib">groupalign</kw> is <quote>left</quote>,
<quote>right</quote>, or <quote>center</quote>, the alignment point is
defined to be at the group's left edge, at its right edge, or halfway
between these edges, respectively. The meanings of <quote>left edge</quote>
and <quote>right edge</quote> are as discussed above in relation to <kw
role="element">malignmark</kw>.</p>
<p>If <kw role="attrib">groupalign</kw> is <quote>decimalpoint</quote>,
the alignment point is the right edge of the last character before the
decimal point. The decimal point is the first <quote>.</quote> character
(ASCII 0x2e) in the first <kw role="element">mn</kw> element found along
the alignment group's baseline. More precisely, the alignment group is
scanned recursively, depth-first, for the first <kw role="element">mn</kw>
element, descending into all arguments of each element of the types
<kw role="element">mrow</kw> (including inferred
<kw role="element">mrow</kw>s), <kw role="element">mstyle</kw>,
<kw role="element">mpadded</kw>, <kw role="element">mphantom</kw>,
<kw role="element">mfenced</kw>, or <kw role="element">msqrt</kw>,
descending into only the first argument of each <quote>scripting</quote> element
(<kw role="element">msub</kw>, <kw role="element">msup</kw>,
<kw role="element">msubsup</kw>, <kw role="element">munder</kw>,
<kw role="element">mover</kw>, <kw role="element">munderover</kw>,
<kw role="element">mmultiscripts</kw>) or of each
<kw role="element">mroot</kw> or <kw role="element">semantics</kw> element,
descending into only the selected sub-expression of each
<kw role="element">maction</kw> element, and skipping the content of all
other elements. The first <kw role="element">mn</kw> so found always
contains the alignment point, which is the right edge of the last
character before the first decimal point in the content of the
<kw role="element">mn</kw> element. If there is no decimal point in the
<kw role="element">mn</kw> element, the alignment point is the right edge
of the last character in the content. If the decimal point is the
first character of the <kw role="element">mn</kw> element's content, the
right edge of a zero-width character inserted before the decimal point
is used. If no <kw role="element">mn</kw> element is found, the right
edge of the entire alignment group is used (as for
<kw role="attrib">groupalign</kw>="right").</p>
<p>In order to permit alignment on decimal points in
<kw role="element">cn</kw> elements, a MathML application can convert a
content expression into a presentation expression that renders the
same way before searching for decimal points as described above.</p>
<p>If characters other than <quote>.</quote> should be used as
<quote>decimal points</quote> for alignment, they should be preceded by <kw
role="element">malignmark</kw> elements within the <kw
role="element">mn</kw> token's content itself.</p>
<p>For any of the <kw role="attrib">groupalign</kw> values, if an explicit
<kw role="element">malignmark</kw> element is present anywhere within
the group, the position it specifies (described earlier) overrides the
automatic determination of alignment point from the
<kw role="attrib">groupalign</kw> value.</p>
</div4>
<div4><head>Inheritance of <kw role="attrib">groupalign</kw> values</head>
<p>It is not usually necessary to put a <kw role="attrib">groupalign</kw>
attribute on every <kw role="element">maligngroup</kw> element. Since
this attribute is usually the same for every group in a column of
alignment groups to be aligned, it can be inherited from an attribute
on the <kw role="element">mtable</kw> that was used to set up the
alignment scope as a whole, or from the <kw role="element">mtr</kw> or
<kw role="element">mtd</kw> elements surrounding the alignment group. It
is inherited via an <quote>inheritance path</quote> that proceeds from
<kw role="element">mtable</kw> through successively contained
<kw role="element">mtr</kw>, <kw role="element">mtd</kw>, and
<kw role="element">maligngroup</kw> elements. There is exactly one
element of each of these kinds in this path from an
<kw role="element">mtable</kw> to any alignment group inside it. In
general, the value of <kw role="attrib">groupalign</kw> will be
inherited by any given alignment group from the innermost element
that surrounds the alignment group and provides an explicit
setting for this attribute.</p>
<p>Note, however, that each <kw role="element">mtd</kw> element needs, in
general, a list of <kw role="attrib">groupalign</kw> values, one for each
<kw role="element">maligngroup</kw> element inside it, rather than just
a single value. Furthermore, an <kw role="element">mtr</kw> or
<kw role="element">mtable</kw> element needs, in general, a list of lists
of <kw role="attrib">groupalign</kw> values, since it spans multiple
<kw role="element">mtable</kw> columns, each potentially acting as an
alignment scope. Such lists of group-alignment values are specified
using the following syntax rules:
<!-- TODO: use appropriate element for syntax rules here -->
<eg>
group-alignment := left | right | center | decimalpoint
group-alignment-list := group-alignment +
group-alignment-list-list := ( '{' group-alignment-list '}' ) +
</eg>
</p>
<p>As described in <specref ref="fund_attval"/>, <code>|</code> separates
alternatives; <code>+</code> represents optional repetition (i.e. 1 or
more copies of what precedes it), with extra values ignored and the
last value repeated if necessary to cover additional table columns or
alignment group columns; <code>'{'</code> and <code>'}'</code>
represent literal braces; and <code>(</code> and <code>)</code> are
used for grouping, but do not literally appear in the attribute
value.</p>
<p>The permissible values of the <kw role="attrib">groupalign</kw> attribute of the
elements that have this attribute are specified using the above
syntax definitions as follows:
<table border="1">
<thead>
<tr>
<td>Element type</td>
<td>groupalign attribute syntax</td>
<td>default value</td>
</tr>
</thead>
<tbody>
<tr>
<td><kw role="element">mtable</kw></td>
<td>group-alignment-list-list</td>
<td>{left}</td>
</tr>
<tr>
<td><kw role="element">mtr</kw></td>
<td>group-alignment-list-list</td>
<td>inherited from <kw role="element">mtable</kw> attribute</td>
</tr>
<tr>
<td><kw role="element">mtd</kw></td>
<td>group-alignment-list</td>
<td>inherited from within <kw role="element">mtr</kw> attribute</td>
</tr>
<tr>
<td><kw role="element">maligngroup</kw></td>
<td>group-alignment</td>
<td>inherited from within <kw role="element">mtd</kw> attribute</td>
</tr>
</tbody>
</table>
</p>
<p>In the example near the beginning of this section, the group
alignment values could be specified on every <kw role="element">mtd</kw>
element using <kw role="attrib">groupalign</kw> = <quote>decimalpoint left left
decimalpoint left left decimalpoint</quote>, or on every
<kw role="element">mtr</kw> element using <kw role="attrib">groupalign</kw> =
<quote>{decimalpoint left left decimalpoint left left decimalpoint}</quote>, or
(most conveniently) on the <kw role="element">mtable</kw> as a whole
using <kw role="attrib">groupalign</kw> = <quote>{decimalpoint left left decimalpoint
left left decimalpoint}</quote>, which provides a single braced list of
group-alignment values for the single column of expressions to be
aligned.</p>
</div4>
<div4><head>MathML representation of an alignment example</head>
<p>The above rules are sufficient to explain the MathML representation
of the example given near the start of this section.
To repeat the example, the desired rendering is:
<eg><![CDATA[
8.44x + 55 y = 0
3.1 x - 0.7y = -1.1
]]></eg>
</p>
<p>One way to represent that in MathML is:
<eg role='mathml'><![CDATA[
<mtable groupalign="decimalpoint left left decimalpoint left left decimalpoint">
<mtr>
<mtd>
<mrow>
<mrow>
<mrow>
<maligngroup/>
<mn> 8.44 </mn>
<mo> ⁢ </mo>
<maligngroup/>
<mi> x </mi>
</mrow>
<maligngroup/>
<mo> + </mo>
<mrow>
<maligngroup/>
<mn> 55 </mn>
<mo> ⁢ </mo>
<maligngroup/>
<mi> y </mi>
</mrow>
</mrow>
<maligngroup/>
<mo> = </mo>
<maligngroup/>
<mn> 0 </mn>
</mrow>
</mtd>
<mtd>
<mrow>
<mrow>
<mrow>
<maligngroup/>
<mn> 3.1 </mn>
<mo> ⁢ </mo>
<maligngroup/>
<mi> x </mi>
</mrow>
<maligngroup/>
<mo> - </mo>
<mrow>
<maligngroup/>
<mn> 0.7 </mn>
<mo> ⁢ </mo>
<maligngroup/>
<mi> y </mi>
</mrow>
</mrow>
<maligngroup/>
<mo> = </mo>
<maligngroup/>
<mrow>
<mo> - </mo>
<mn> 1.1 </mn>
</mrow>
</mrow>
</mtd>
</mtr>
</mtable>
]]></eg>
</p>
</div4>
<div4><head>Further details of alignment elements</head>
<p>The alignment elements <kw role="element">maligngroup</kw> and
<kw role="element">malignmark</kw> can occur outside of alignment
scopes, where they are ignored. The rationale behind this is that in
situations in which MathML is generated, or copied from another
document, without knowing whether it will be placed inside an
alignment scope, it would be inconvenient for this to be an error.</p>
<p>An <kw role="element">mtable</kw> element can be given the attribute <kw
role="attrib">alignmentscope</kw>=<kw role="attval">false</kw> to cause its
columns not to act as alignment scopes. In general, this attribute has the
syntax <code>(true | false) +</code>; if its value is a list of boolean
values, each boolean value applies to one column, with the last value
repeated if necessary to cover additional columns, or with extra values
ignored. Columns that are not alignment scopes are part of the alignment
scope surrounding the <kw role="element">mtable</kw> element, if there is
one. Use of <kw role="attrib">alignmentscope</kw>=<kw
role="attval">false</kw> allows nested tables to contain <kw
role="element">malignmark</kw> elements for aligning the inner table in the
surrounding alignment scope.</p>
<p>As discussed above, processing of alignment for content elements is
not well-defined, since MathML does not specify how content elements
should be rendered. However, many MathML applications are likely to find it
convenient to internally convert content elements to presentation
elements that render the same way. Thus, as a general rule, even if a
renderer does not perform such conversions internally, it is
recommended that the alignment elements should be processed as if it
did perform them.</p>
<p>A particularly important case for renderers to handle gracefully is the
interaction of alignment elements with the <kw role="element">matrix</kw>
content element, since this element may or may not be internally converted
to an expression containing an <kw role="element">mtable</kw> element for
rendering. To partially resolve this ambiguity, it is suggested, but not
required, that if the <kw role="element">matrix</kw> element is converted
to an expression involving an <kw role="element">mtable</kw> element, that
the <kw role="element">mtable</kw> element be given the attribute <kw
role="attrib">alignmentscope</kw>=<kw role="attval">false</kw>, which will
make the interaction of the <kw role="element">matrix</kw> element with the
alignment elements no different than that of a generic presentation element
(in particular, it will allow it to contain <kw
role="element">malignmark</kw> elements that operate within the alignment
scopes created by the columns of an <kw role="element">mtable</kw> that
contains the <kw role="element">matrix</kw> element in one of its table
cells).</p>
<p>The effect of alignment elements within table cells that have
non-default values of the <kw role="attrib">columnspan</kw> or <kw
role="attrib">rowspan</kw> attributes is not specified, except that such
use of alignment elements is not an error. Future versions of MathML may
specify the behavior of alignment elements in such table cells.</p>
<p>The effect of possible linebreaking of an <kw role="element">mtable</kw>
element on the alignment elements is not specified.</p>
</div4>
<div4><head>A simple alignment algorithm</head>
<p>A simple algorithm by which a MathML application can perform the
alignment specified in this section is given here. Since the alignment
specification is deterministic (except for the definition of the left
and right edges of a character), any correct MathML alignment
algorithm will have the same behavior as this one. Each
<kw role="element">mtable</kw> column (alignment scope) can be treated
independently; the algorithm given here applies to one
<kw role="element">mtable</kw> column, and takes into account the
alignment elements, the <kw role="attrib">groupalign</kw> attribute described in
this section, and the <kw role="attrib">columnalign</kw> attribute described
under <kw role="element">mtable</kw> (<specref
ref="presm_mtable"/>).</p>
<p>First, a rendering is computed for the contents of each table cell
in the column, using zero width for all
<kw role="element">maligngroup</kw> and <kw role="element">malignmark</kw>
elements. The final rendering will be identical except for horizontal
shifts applied to each alignment group and/or table cell. The
positions of alignment points specified by any
<kw role="element">malignmark</kw> elements are noted, and the remaining
alignment points are determined using <kw role="attrib">groupalign</kw>
values.</p>
<p>For each alignment group, the horizontal positions of the left
edge, alignment point, and right edge are noted, allowing the width of
the group on each side of the alignment point (left and right) to be
determined. The sum of these two <quote>side-widths</quote>, i.e. the sum of the
widths to the left and right of the alignment point, will equal the
width of the alignment group.</p>
<p>Second, each column of alignment groups, from left to right, is
scanned. The <mi>i</mi>th scan covers the <mi>i</mi>th
alignment group in each table cell containing any alignment
groups. Table cells with no alignment groups, or with fewer than
<mi>i</mi> alignment groups, are ignored. Each scan computes two
maximums over the alignment groups scanned: the maximum width to the
left of the alignment point, and the maximum width to the right of the
alignment point, of any alignment group scanned.</p>
<p>The sum of all the maximum widths computed (two for each column of
alignment groups) gives one total width, which will be the width of
each table cell containing alignment groups. Call the maximum number
of alignment groups in one cell <mi>n</mi>; each such cell's width
is divided into 2<mi>n</mi> adjacent sections, called
L(<mi>i</mi>) and R(<mi>i</mi>) for <mi>i</mi> from 1 to
<mi>n</mi>, using the 2<mi>n</mi> maximum side-widths computed
above; for each <mi>i</mi>, the width of all sections called
L(<mi>i</mi>) is the maximum width of any cell's <mi>i</mi>th
alignment group to the left of its alignment point, and the width of
all sections called R(<mi>i</mi>) is the maximum width of any
cell's <mi>i</mi>th alignment group to the right of its alignment
point.</p>
<p>The alignment groups are then positioned in the unique way that
places the part of each <mi>i</mi>th group to the left of its
alignment point in a section called L(<mi>i</mi>), and places the
part of each <mi>i</mi>th group to the right of its alignment
point in a section called R(<mi>i</mi>). This results in the
alignment point of each <mi>i</mi>th group being on the boundary
between adjacent sections L(<mi>i</mi>) and R(<mi>i</mi>), so
that all alignment points of <mi>i</mi>th groups have the same
horizontal position.</p>
<p>The widths of the table cells that contain no alignment groups
were computed as part of the initial rendering, and may be different
for each cell, and different from the single width used for cells
containing alignment groups. The maximum of all the cell widths (for
both kinds of cells) gives the width of the table column as a
whole.</p>
<p>The position of each cell in the column is determined by the
applicable part of the value of the <kw role="attrib">columnalign</kw> attribute
of the innermost surrounding <kw role="element">mtable</kw>,
<kw role="element">mtr</kw>, or <kw role="element">mtd</kw> element that
has an explicit value for it, as described in the sections on those
elements. This may mean that the cells containing alignment groups
will be shifted within their column, in addition to their alignment
groups having been shifted within the cells as described above, but
since each such cell has the same width, it will be shifted the same
amount within the column, thus maintaining the vertical alignment of
the alignment points of the corresponding alignment groups in each
cell.</p>
</div4>
</div3>
</div2>
<div2 id="presm_enliven"><head>Enlivening Expressions</head>
<div3 id="presm_maction"><head>Bind Action to Sub-Expression (<kw role="element">maction</kw>)</head>
<p>There are many ways in which it might be desirable to make
mathematical content active. Adding a link to a MathML sub-expression
is one basic kind of interactivity. See <specref ref="interf_link"/>.
However, many other kinds of interactivity cannot be easily
accommodated by generic linking mechanisms. For example, in lengthy
mathematical expressions, the ability to <quote>fold</quote>
expressions might be provided, i.e. a renderer might allow a reader to
toggle between an ellipsis and a much longer expression that it
represents.</p>
<p>To provide a mechanism for binding actions to expressions, MathML
provides the <kw role="element">maction</kw> element. This element accepts any
number of sub-expressions as arguments.</p>
<div4><head>Attributes</head>
<p>In addition to the attributes listed below, this element permits
<kw role="attrib">id</kw>,
<kw role="attrib">xref</kw>, <kw role="attrib">class</kw> and
<kw role="attrib">style</kw> attributes,
as described in <specref ref="fund_globatt"/>.
<table border="1">
<thead>
<tr>
<td>Name</td>
<td>values</td>
<td>default</td>
</tr>
</thead>
<tbody>
<tr>
<td>actiontype</td>
<td>(described below)</td>
<td>(required attribute, no default value)</td>
</tr>
<tr>
<td>selection</td>
<td>positive-integer</td>
<td>1</td>
</tr>
</tbody>
</table>
</p>
<p>By default, MathML applications that do not recognize the specified
<kw role="attrib">actiontype</kw> should render the selected sub-expression as
defined below. If no selected sub-expression exists, it is a MathML
error; the appropriate rendering in that case is as described in
<specref ref="interf_error"/>.</p>
<p>Since a MathML-compliant application is not required to recognize any
particular <kw role="attrib">actiontype</kw>s, an application can be fully MathML
compliant just by implementing the above-described default behavior.</p>
<p>The <kw role="attrib">selection</kw> attribute is provided for those
<kw role="attrib">actiontype</kw>s that permit someone viewing a document to select one of
several sub-expressions for viewing. Its value should be a positive
integer that indicates one of the sub-expressions of the
<kw role="element">maction</kw> element, numbered from 1 to the number of
children of the element. When this is the case, the sub-expression so
indicated is defined to be the <quote>selected sub-expression</quote> of the
<kw role="element">maction</kw> element; otherwise the <quote>selected
sub-expression</quote> does not exist, which is an error. When the
<kw role="attrib">selection</kw> attribute is not specified (including for
actiontypes for which it makes no sense), its default value is 1, so
the selected sub-expression will be the first sub-expression.</p>
<!--
<p>Note that the <kw role="attrib">selection</kw> attribute of an
<kw role="element">maction</kw> element affects not only the rendering of
the element itself, but potentially the rendering of elements
containing it; this can be due either to the reference to an
<kw role="element">maction</kw>'s selected sub-expression in the
definition of embellished operator in <specref ref="presm_mo"/>, or to alignment
elements contained in the selected sub-expression (<specref
ref="presm_malign"/>). This means that a change of the selection
by the viewer may require a rerendering of the surroundings, not just
their repositioning due to a change in size of the
<kw role="element">maction</kw> element itself.</p>
-->
<p>Furthermore, as described in <specref ref="interf"/>, if a MathML
application responds to a user command to copy a MathML sub-expression to
the environment's <quote>clipboard</quote>, any <kw
role="element">maction</kw> elements present in what is copied should
be given selection attributes that correspond to their selection
state in the MathML rendering at the time of the copy command.</p>
<p>A suggested list of <kw role="attrib">actiontype</kw>s and their associated
actions is given below. Keep in mind, however, that this list is
mainly for illustration, and recognized values and behaviors will vary
from application to application.
<glist>
<gitem>
<label><maction actiontype="toggle" selection="positive-integer" > (first expression) (second expression)... </maction></label>
<def><p>For this action type, a renderer would alternately display the
given expressions, cycling through them when a reader clicked on the
active expression, starting with the selected expression and updating
the <kw role="attrib">selection</kw> attribute value as described above.
Typical uses would be for exercises in education, ellipses in long
computer algebra output, or to illustrate alternate notations. Note
that the expressions may be of significantly different size, so that
size negotiation with the browser may be desirable. If size
negotiation is not available, scrolling, elision, panning, or some
other method may be necessary to allow full viewing.</p></def>
</gitem>
<gitem><label><maction actiontype="statusline"> (expression) (message) </maction></label>
<def><p>In this case, the renderer would display the expression in
context on the screen. When a reader clicked on the expression or
moved the mouse over it, the renderer would send a rendering of the
message to the browser statusline. Since most browsers in the
foreseeable future are likely to be limited to displaying text on their
statusline, authors would presumably use plain text in an
<kw role="element">mtext</kw> element for the message in most circumstances.
For non-<kw role="element">mtext</kw> messages, renderers might provide a
natural language translation of the markup, but this is not
required.</p></def>
</gitem>
<gitem><label><maction actiontype="tooltip"> (expression) (message) </maction></label>
<def><p>Here the renderer would also display the expression in context
on the screen. When the mouse pauses over the expression for a long
enough delay time, the renderer displays a rendering of the message in
a pop-up <quote>tooltip</quote> box near the expression. These message boxes are
also sometimes called <quote>balloon help</quote> boxes. Presumably authors would
use plain text in an <kw role="element">mtext</kw> element for the message
in most circumstances. For non-<kw role="element">mtext</kw> messages,
renderers may provide a natural language translation of the markup if
full MathML rendering is not practical, but this is not
required.</p></def>
</gitem>
<gitem>
<label><maction actiontype="highlight" my:color="red" my:background="yellow"> expression </maction></label>
<def><p>In this case, a renderer might highlight the enclosed expression on
a <quote>mouse-over</quote> event. In the example given above,
non-standard attributes from another namespace are being used to pass
additional information to renderers that support them, without violating the MathML DTD (see
<specref ref="interf_unspecified"/>). The <kw role="attrib">my:color</kw> attribute
changes the color of the characters in the presentation, while the
<kw role="attrib">my:background</kw> attribute changes the color of the background
behind the characters.</p></def>
</gitem>
<gitem><label><maction actiontype="menu" selection="1" > (menu item 1) (menu item 2) ... </maction></label>
<def><p>This action type instructs a renderer to provide a pop up
menu. This allows a one-to-many linking capability. Note that the menu
items may be other <maction
actiontype="menu">...</maction> expressions, thereby allowing
nested menus. It is assumed that the user choosing a menu item would
invoke some kind of action associated with that item. Such action
might be completely handled by the renderer itself or it might trigger
some kind of event within the browser that could be linked to other
programming logic. </p></def>
</gitem>
</glist>
</p>
</div4>
</div3>
</div2>
</div1>