This specification defines the Mathematical Markup Language, or
MathML. MathML is a markup language
for describing mathematical notation and capturing
both its structure and content. The goal of MathML is to enable
mathematics to be served, received, and processed on the World Wide
Web, just as [HTML] has
enabled this functionality for text.
This specification of the markup language MathML is intended
primarily for a readership consisting of those who will be
developing or implementing renderers or editors using it, or
software that will communicate using MathML as a protocol for input
or output. It is not a User's Guide but rather a
reference document.
MathML can be used to encode both mathematical notation and
mathematical content. About thirty-eight of the MathML tags describe
abstract notational structures, while another about one hundred and
seventy provide a way of unambiguously specifying the intended
meaning of an expression. Additional chapters discuss how the MathML
content and presentation elements interact, and how MathML renderers
might be implemented and should interact with browsers. Finally,
this document addresses the issue of special characters used for
mathematics, their handling in MathML, their presence in Unicode,
and their relation to fonts.
While MathML is human-readable, authors typically will
use equation editors, conversion
programs, and other specialized software tools to generate
MathML. Several versions of such MathML tools exist,
both freely available software and commercial
products, and more are under development.
MathML was originally specified as an XML application and most of the
examples in this specification assume that syntax. Other syntaxes are possible, most
notably
[HTML] specifies the syntax for MathML in HTML. Unless explicitly noted,
the examples in this specification are also valid HTML syntax.
This section describes the status of this
document at the time of its publication. A list of current W3C
publications and the latest revision of this technical report can be found
in the W3C technical reports index at
https://www.w3.org/TR/.
This is a draft document and may be updated, replaced or obsoleted by other
documents at any time. It is inappropriate to cite this document as other
than work in progress.
This document was produced by a group
operating under the
W3C Patent
Policy.
W3C maintains a
public list of any patent disclosures
made in connection with the deliverables of
the group; that page also includes
instructions for disclosing a patent. An individual who has actual
knowledge of a patent which the individual believes contains
Essential Claim(s)
must disclose the information in accordance with
section 6 of the W3C Patent Policy.
Mathematics and its notations have evolved over several centuries, or even millennia.
To the experienced reader, mathematical notation conveys
a large amount of information quickly and compactly.
And yet, while the symbols and arrangements of the notations
have a deep correspondence to the semantic structure and meaning
of the mathematics being represented, the notation and semantics
are not the same. The semantic symbols and structures are
subtly distinct from those of the notation.
Thus, there is a need for a markup language
which can represent both the traditional displayed notations
of mathematics, as well as its semantic content.
While the traditional rendering is useful to sighted readers,
the markup language must also support accessibility.
The semantic forms must support a variety of computational purposes.
Both forms should be appropriate to all educational levels from
elementary to research.
MathML is a markup language for describing mathematics.
It uses XML syntax when used standalone or within other XML,
or HTML syntax when used within HTML documents.
Conceptually, MathML consists of two main strains of markup:
Presentation markup is used to display mathematical expressions;
and Content markup is used to convey mathematical meaning.
These two strains, along with other external representations,
can be combined using parallel markup.
This specification is organized as follows:
2. MathML Fundamentals discusses Fundamentals common to Presentation and Content markup;
3. Presentation Markup and 4. Content Markup cover Presentation and Content markup,
respectively;
5. Annotating MathML discusses how markup may be annotated, particularly for accessibility,
as well as how Presentation, Content and other formats may be combined;
6. Interactions with the Host Environment addresses how MathML interacts with applications;
Finally, a discussion of special symbols,
and issues regarding characters, entities and fonts,
is given in 7. Characters, Entities and Fonts.
The specification of MathML is developed in two layers.
MathML Core ([MathML-Core]) covers (most of) Presentation Markup,
with the focus being the precise details of displaying mathematics in web browsers.
MathML Full, this specification, extends MathML Core
primarily by defining Content MathML, in 4. Content Markup.
It also defines extensions to Presentation MathML consisting
of additional attributes, elements or enhanced syntax of attributes.
These are defined for compatibility with legacy MathML,
as well as to cover 3.1.7 Linebreaking of Expressions, 3.6 Elementary Math
and other aspects not included in level 1 of MathML Core
but which may be incorporated into future versions of MathML Core.
It is intended that MathML Full is a proper superset of MathML Core.
Moreover, it is intended that any valid Core Markup be considered as valid Full Markup as well.
It is also intended that an otherwise conforming implementation of MathML Core,
which also implements parts or all of the extensions of MathML Full,
should continue to be considered a conforming implementation of MathML Core.
In addition to these two specifications, the Math WG group has developed the non-normative
Notes on MathML
that contains additional examples and information to help understand best practices when using MathML.
The basic ‘syntax’ of MathML is
defined using XML syntax,
but other syntaxes that can encode labeled trees are possible. Notably the HTML parser
may also be used with MathML.
Upon this, we layer a ‘grammar’, being the rules for allowed elements,
the order in which they can appear,
and how they may be contained within each other,
as well as additional syntactic rules for the values of attributes.
These rules are defined by this specification,
and formalized by a RelaxNG schema [RELAXNG-SCHEMA] in A. Parsing MathML.
Derived schema in other formats, DTD (Document Type Definition)
and XML Schema [XMLSchemas] are also provided.
MathML's character set consists of any
Unicode characters [Unicode] allowed by the syntax being used. (See for example [XML] or [HTML].)
The use of Unicode characters for mathematics is
discussed in 7. Characters, Entities and Fonts.
When the xmlns attribute is used as a
prefix, it declares a prefix which can then be used to explicitly associate other
elements
and attributes with a particular namespace.
When embedding MathML within HTML using XML syntax, one might use:
HTML does not support namespace extensibility in the same way, the HTML parser
has in-built knowledge of the HTML, SVG and MathML namespaces. xmlns attributes are
just treated as normal attributes. Thus when using the HTML serialisation of MathML,
prefixed element names must not be used. xmlns=http://www.w3.org/1998/Math/MathML
may be used on the math element, it will be ignored by the HTML parser.
If a MathML expression is likely to be in contexts where it may be parsed by an XML
parser or an HTML parser, it SHOULD
use the following form to ensure maximum compatibility:
There are presentation elements that conceptually accept only
a single argument, but which for convenience have been written to accept any number
of children;
then we infer an mrow containing those children which acts as
the argument to the element in question; see 3.1.3.1 Inferred <mrow>s.
In the detailed discussions of element syntax given with each
element throughout the MathML specification, the number of arguments required and
their order, as well as other constraints on the content, are specified.
This information is also tabulated
for the presentation elements in 3.1.3 Required Arguments.
This document only recommends (i.e., does not require) specific
ways of rendering Presentation MathML; this is in order to allow
for medium-dependent rendering and for implementations not using
the CSS based Web Platform.
MathML elements take attributes with values that further specialize
the meaning or effect of the element. Attribute names are shown in a
monospaced font throughout this document. The meanings of attributes and their
allowed values are described within the specification of each element.
The syntax notation explained in this section is used in specifying allowed values.
2.1.5.1 MathML仕様書で使われる構文表記 Syntax notation used in the MathML specification
To describe the MathML-specific syntax of
attribute values, the following conventions and notations are
used for most attributes in the present document.
表記 Notation
何と一致するか What it matches
符号無し整数 unsigned-integer
[MathMLコア]で定義された, 最初の文字がハイフンマイナス文字(-)でもプラス記号(+)でもない整数 As defined in [MathML-Core], an integer, whose first character is neither
U+002D HYPHEN-MINUS character (-) nor
U+002B PLUS SIGN (+).
正の整数 positive-integer
符号無し整数の文字列, ただし, 単に"0"(U+0030)のみから成るものは除く, 正の整数を表す An unsigned-integer not consisting solely of "0"s (U+0030), representing a positive integer
整数 integer
必須でない"-"(U+002D), それに続く符号無し整数, 整数を表す an optional "-" (U+002D), followed by an unsigned-integer,
and representing an integer
符号無し数 unsigned-number
[CSS-VALUES-3]で定義された値, 最初の文字がハイフンマイナス文字(-)でもプラス記号(+)でもない数, 10進数で終わる数(有理数の型)を表す value as defined in
[CSS-VALUES-3] number, whose first character is neither
U+002D HYPHEN-MINUS character (-) nor
U+002B PLUS SIGN (+),
representing a non-negative terminating decimal number
(a type of rational number)
数 number
必須でない接頭辞"-"(U+002D), それに続く符号無し数, 10進数で終わる数(有理数の型)を表す an optional prefix of "-" (U+002D), followed by an unsigned number,
representing a terminating decimal number (a type of rational number)
文字 character
単独の空白でない文字 a single non-whitespace character
文字列 string
任意の空で無い有限の文字の文字列 an arbitrary, nonempty and finite, string of characters
文書の中で唯一である識別子, XML勧告[XML]の名前の構文を満足しなければならない an identifier, unique within the document;
must satisfy the NAME syntax of the XML recommendation [XML]
参照先のid idref
文書の中の他の要素を参照する識別子, XML勧告[XML]の名前の構文を満足しなければならない an identifier referring to another element within the document;
must satisfy the NAME syntax of the XML recommendation [XML]
URI
統一資源識別子[RFC3986]. 属性の値は, 何らかの一連のXML文字で与えられた, 何らかのURIとして構文の中で分類されることに注意して下さい. URLとして文字列を利用する必要のあるシステムは, URLで認められていない文字を, HHが16進数のバイト値である%HHというパーセントエンコードを利用して, UTF-8文字コードのバイトでコード化しなければなりません. これは, そのような属性値をIRIとして, もっと一般にLEIRIとして解釈することを確かにします. [IRI]を参照して下さい. a Uniform Resource Identifier [RFC3986]. Note that the attribute value
is typed in the schema as anyURI which allows any sequence of XML characters.
Systems needing to use this string as a URI must encode the bytes of the UTF-8 encoding
of any characters not allowed in URI using %HH encoding where HH are the byte value
in hexadecimal.
This ensures that such an attribute value may be interpreted as an IRI,
or more generally a LEIRI, see [IRI].
The ‘types’ described above, except for string,
may be combined into composite patterns using the following operators. The whole
attribute value must be delimited by single (') or double (") quotation marks in the
marked up
document. Note that double quotation marks are often used in this specification to
mark up
literal expressions; an example is the "-" in line 5 of the table above.
In the table
below a form f means an instance of a type described in the table above.
The combining operators are shown in order of precedence from highest
to lowest:
表記 Notation
何と一致するか What it matches
( f )
fと同じ same as f
f ?
0または1つのf an optional instance of f
f *
空白文字で区切られた0以上のf zero or more instances of f, with
separating whitespace characters
f +
空白文字で区切られた1つ以上のf one or more instances of f, with
separating whitespace characters
f1 f2 ... fn
空白文字で区切られていないfiそれぞれの一連のもの one instance of each form fi, in sequence,
with no separating whitespace
f1, f2, ..., fn
(コンマでなく)空白文字で区切られたfiそれぞれの一連のもの one instance of each form fi, in sequence, with
separating whitespace characters (but no commas)
Since some applications are inconsistent about normalization
of whitespace, for maximum interoperability it is advisable to use only
a single whitespace character for separating parts of a value.
Moreover, leading and trailing whitespace in attribute values should be avoided.
For most numerical attributes, only those in a subset of the
expressible values are sensible; values outside this subset are not
errors, unless otherwise specified, but rather are rounded up or down
(at the discretion of the renderer) to the closest value within the
allowed subset. The set of allowed values may depend on the renderer,
and is not specified by MathML.
If a numerical value within an attribute value syntax description
is declared to allow a minus sign ('-'), e.g., number or
integer, it is not a syntax error when one is provided in
cases where a negative value is not sensible. Instead, the value
should be handled by the processing application as described in the
preceding paragraph. An explicit plus sign ('+') is not allowed as
part of a numerical value except when it is specifically listed in the
syntax (as a quoted '+' or "+"), and its presence can change the
meaning of the attribute value (as documented with each attribute
which permits it).
Most presentation elements have attributes that accept values
representing lengths to be used for size, spacing or similar properties.
[MathML-Core] accepts lengths only in the
<length-percentage>
syntax defined in [CSS-VALUES-3].
MathML Full extends length syntax by accepting also a namedspace
being one of:
In addition, the attributes on mpadded
allow three pseudo-units, height,
depth and width (taking the place of one of the usual CSS units)
denoting the original dimensions of the content.
MathML 3 also allowed a deprecated usage with lengths specified as
a number without a unit. This was interpreted as a multiple of the
reference value. This form is considered invalid in MathML 4.
2.1.5.2.1 単位についての追加の注意点 Additional notes about units
Two additional aspects of relative units must be clarified, however.
First, some elements such as 3.4 Script and Limit Schemata or mfrac
implicitly switch to smaller font sizes for some of their arguments.
Similarly, mstyle can be used to explicitly change
the current font size. In such cases, the effective values of
an em or ex inside those contexts will be
different than outside. The second point is that the effective value
of an em or ex used for an attribute value
can be affected by changes to the current font size.
Thus, attributes that affect the current font size,
such as mathsize
and scriptlevel, must be processed before
evaluating other length valued attributes.
Default values for MathML attributes are, in general, given along with the
detailed descriptions of specific elements in the text. Default values
shown in plain text in the tables of attributes for an element are literal,
but when italicized are descriptions of how default values can be computed.
Default values described as inherited are taken from the
rendering environment, as described in 3.3.4 Style Change <mstyle>,
or in some cases (which are described individually) taken from the values of other
attributes of surrounding elements, or from certain parts of those
values. The value used will always be one which could have been specified
explicitly, had it been known; it will never depend on the content or
attributes of the same element, only on its environment. (What it means
when used may, however, depend on those attributes or the content.)
Default values described as automatic should be computed by
a MathML renderer in a way which will produce a high-quality rendering; how
to do this is not usually specified by the MathML specification. The value
computed will always be one which could have been specified explicitly, had
it been known, but it will usually depend on the element content and
possibly on the context in which the element is rendered.
The single or double quotes which are required around attribute values
in an XML start tag are not shown in the tables of attribute value syntax
for each element, but are around attribute values in examples in the
text, so that the pieces of code shown are correct.
Note that, in general, there is no mechanism in MathML to simulate the
effect of not specifying attributes which are inherited or
automatic. Giving the words inherited or
automatic explicitly will not work, and is not generally
allowed. Furthermore, the mstyle element (3.3.4 Style Change <mstyle>)
can even be used to change the default values of presentation attributes
for its children.
Note also that these defaults describe the
behavior of MathML applications when an attribute is not supplied;
they do not indicate a value that will be filled in by an XML parser,
as is sometimes mandated by DTD-based specifications.
In general, there are a number of
properties of MathML rendering that may be thought of as overall
properties of a document, or at least of sections of a large
document. Examples might be mathsize (the math font
size: see 3.2.2 Mathematics style attributes common to token elements), or the
behavior in setting limits on operators such as integrals or sums
(e.g., movablelimits or displaystyle), or
upon breaking formulas over lines (e.g.
linebreakstyle); for such attributes see several
elements in 3.2 Token Elements.
These may be thought to be inherited from some such
containing scope. Just above we have mentioned the setting of default
values of MathML attributes as inherited or
automatic; there is a third source of global default values
for behavior in rendering MathML, a MathML operator dictionary. A
default example is provided in B. Operator Dictionary.
This is also discussed in 3.2.5.6.1 The operator dictionary and examples are given in
3.2.5.2.1 Dictionary-based attributes.
2.1.6 全てのMathML要素で利用される属性 Attributes Shared by all MathML Elements
In addition to the attributes described specifically for each element,
the attributes in the following table are allowed on every MathML element.
Also allowed are attributes from the xml namespace, such as xml:lang,
and attributes from namespaces other than MathML,
which are ignored by default.
リンク, 相互参照, 並列のマークアップに対応するために, 要素と結び付けられた唯一の識別子を確立します. xrefや5.2.9 並列のマークアップを参照して下さい. Establishes a unique identifier associated with the element
to support linking, cross-references and parallel markup.
See xref and 5.2.9 Parallel Markup.
要素を[CSS21]を利用して書式の種類の集合と結び付けます. MathMLとCSSの相互作用の議論については, 6.5 MathMLと一緒にCSSを利用するを参照して下さい. Associates the element with a set of style classes for use with
[CSS21].
See 6.5 Using CSS with MathML for discussion of the interaction of MathML and CSS.
書式情報を[CSS21]を利用して要素と結び付けます. MathMLとCSSの相互作用の議論については, 6.5 MathMLと一緒にCSSを利用するを参照して下さい. Associates style information with the element for use with
[CSS21].
See 6.5 Using CSS with MathML for discussion of the interaction
of MathML and CSS.
All MathML presentation elements accept intent and arg attributes to support specifying
intent. These are more fully described in
5.1 The intent attribute.
intent属性は, 5.1 intent属性でより詳細に説明されています. この属性は, プレゼンテーション要素において, 式の意図している意味についての情報を示したり, 主に音声や点字のアクセシビリティに配慮した表現を導入したりするのに使用されるでしょう. The intent attribute is more fully described
in 5.1 The intent attribute. It may be used on presentation
elements to give information about the intended meaning of the
expression, mainly for guiding audio or braille accessible
renderings.
arg属性は, 5.1 intent属性でより詳細に説明されています. この属性は, 祖先要素のintentの式から参照する要素に名前を付けるのに使用されるでしょう. The arg attribute is more fully described
in 5.1 The intent attribute. It may be used to name an element to be referenced from an
intent expression on an ancestor element.
In MathML, as in XML, whitespace means simple spaces,
tabs, newlines, or carriage returns, i.e., characters with hexadecimal
Unicode codes U+0020, U+0009, U+000A, or
U+000D, respectively; see also the discussion of whitespace in Section 2.3 of
[XML].
MathML ignores whitespace occurring outside token elements.
Non-whitespace characters are not allowed there. Whitespace occurring
within the content of token elements, except for <cs>, is normalized as follows. All whitespace at the beginning and end of the content is
removed, and whitespace internal to content of the element is
collapsed canonically, i.e., each sequence of 1 or more
whitespace characters is replaced with one space character (U+0020, sometimes
called a blank character).
例えば, <mo> ( </mo>は<mo>(</mo>に等しく, また,
For example, <mo> ( </mo> is equivalent to
<mo>(</mo>, and
Authors wishing to encode white space characters at the start or end of
the content of a token, or in sequences other than a single space, without
having them ignored, must use non-breaking space U+00A0 (or nbsp)
or other non-marking characters that are not trimmed.
For example, compare the above use of an mtext element
with
When the first example is rendered, there is nothing before
Theorem, one Unicode space character between Theorem and
1:, and nothing after 1:. In the
second example, a single space character is to be rendered before
Theorem; two spaces, one a Unicode space character and
one a Unicode no-break space character, are to be rendered before
1:; and there is nothing after the
1:.
Note that the value of the xml:space attribute is not relevant
in this situation since XML processors pass whitespace in tokens to a
MathML processor; it is the requirements of MathML processing which specify that
whitespace is trimmed and collapsed.
For whitespace occurring outside the content of the token elements
mi, mn, mo, ms, mtext,
ci, cn, cs, csymbol and annotation,
an mspace element should be used, as opposed to an mtext element containing
only whitespace entities.
MathML specifies a single top-level or root math element,
which encapsulates each instance of
MathML markup within a document. All other MathML content must be
contained in a math element; in other words,
every valid MathML expression is wrapped in outer
<math> tags. The math
element must always be the outermost element in a MathML expression;
it is an error for one math element to contain
another. These considerations also apply when sub-expressions are
passed between applications, such as for cut-and-paste operations;
see 6.3 Transferring MathML.
The math element accepts any of the attributes that can be set on
3.3.4 Style Change <mstyle>, including the common attributes
specified in 2.1.6 Attributes Shared by all MathML Elements.
In particular, it accepts the dir attribute for
setting the overall directionality; the math element is usually
the most useful place to specify the directionality
(see 3.1.5 Directionality for further discussion).
Note that the dir attribute defaults to ltr
on the math element (but inherits on all other elements
which accept the dir attribute); this provides for backward
compatibility with MathML 2.0 which had no notion of directionality.
Also, it accepts the mathbackground attribute in the same sense
as mstyle and other presentation elements to set the background
color of the bounding box, rather than specifying a default for the attribute
(see 3.1.9 Mathematics attributes common to presentation elements).
これらの属性に加えて, math要素は次の属性を持ちます.
In addition to those attributes, the math element accepts:
囲っているMathMLの式が, 縦に分けられたblock(領域)(ディスプレイ形式), または隣接した文章に揃えられるinline(インライン形式)のどちらで描画されるべきか指定します(TEXの一般的な呼び方にならってディスプレイ形式, インライン形式と訳しています). display=blockの場合, displaystyleはtrueで初期化されます. 一方, display=inlineの場合, displaystyleはfalseで初期化されます. どちらの場合でも, scriptlevelは0で初期化されます. (3.1.6 displaystyleとscriptlevel参照). さらに, math要素が大きな文書の中に埋め込まれた場合, blockのmath要素は文書の形式にふさわしい領域要素として(典型的に新しい縦の領域として)扱われるべきで, 一方, inlineのmath要素は行の一部として(典型的に実際に標準の文書の中の一連の言葉であるかのように)扱われるべきです. 特に, この属性は間隔の取り方や改行に影響します. 例えば, inlineのmath要素の中に空白や改行を挿入したり, 何らかの直接の区切りを挿入したりすべきではありません. display属性が無い場合, 描画プログラムが文脈に沿って適切な値に初期化するのは自由です. specifies whether the enclosed MathML expression should be rendered
as a separate vertical block (in display style)
or inline, aligned with adjacent text.
When display=block, displaystyle is initialized
to true,
whereas when display=inline, displaystyle
is initialized to false;
in both cases scriptlevel is initialized to 0
(see 3.1.6 Displaystyle and Scriptlevel).
Moreover, when the math element is embedded in a larger document,
a block math element should be treated as a block element as appropriate
for the document type (typically as a new vertical block),
whereas an inline math element should be treated as inline
(typically exactly as if it were a sequence of words in normal text).
In particular, this applies to spacing and linebreaking: for instance,
there should not be spaces or line breaks inserted between inline math
and any immediately following punctuation.
When the display attribute is missing, a rendering agent is free to initialize
as appropriate to the context.
改行のために使用する最大の幅を指定します. 既定値は, 周囲を囲っている環境で利用可能な最大の幅です. この属性値を決められない場合, 描画ソフトウェアは描画できる無限の幅であると仮定すべきです. specifies the maximum width to be used for linebreaking.
The default is the maximum width available in the surrounding environment.
If that value cannot be determined, the renderer should assume an infinite rendering
width.
式が利用可能な幅に収まるには長過ぎる状況で, 望ましい扱い方を指定します. 後の議論を参照して下さい. specifies the preferred handing in cases where an expression is too long to
fit in the allowed width. See the discussion below.
埋め込まれたMathMLに対応していない利用者のプログラムの代替手段として, 表示する画像を参照するURIを提供します. provides a URI referring to an image to display as a fall-back
for user agents that do not support embedded MathML.
画像を拡大・縮小させることが必要な場合のaltimgを表示する幅を指定します. altimg-heightを参照して下さい. specifies the width to display altimg, scaling the image if necessary;
see altimg-height.
画像を拡大・縮小させることが必要な場合のaltimgを表示する高さを指定します. 属性altimg-widthとaltimg-heightの一方だけが与えられた場合, 画像はアスペクト比を保ったまま, 拡大・縮小されます. 属性がどちらも与えられない場合, 画像は元の大きさのまま表示されるべきです. specifies the height to display altimg, scaling the image if necessary;
if only one of the attributes altimg-width and altimg-height
are given, the scaling should preserve the image's aspect ratio;
if neither attribute is given, the image should be shown at its natural size.
隣接する行の中の要素に対する縦方向の位置揃えを指定します. altimg-valignの正の値は画像の下端を現在の欧文ベースライン(訳注:欧文書体で水平の基準線で大文字の下端の位置)から上にずらし, 負の値は下にずらします. 値"top"は画像の上端を隣接する行の中の要素の上端に合わせます. "center"は画像の中心を隣接する行の中の要素の中心に合わせます. "bottom"は画像の下端を隣接する行の中の要素の下端(必ずしも欧文ベースラインでなくて良い)に合わせます. この属性は, display=inlineの場合のみ効果があります. 既定値では, 画像の下端が欧文ベースラインに揃うことになります. specifies the vertical alignment of the image with respect to adjacent inline material.
A positive value of altimg-valign shifts the bottom of the image above the
current baseline, while a negative value lowers it.
The keyword "top" aligns the top of the image with the top of adjacent inline material;
"center" aligns the middle of the image to the middle of adjacent material;
"bottom" aligns the bottom of the image to the bottom of adjacent material
(not necessarily the baseline). This attribute only has effect
when display=inline.
By default, the bottom of the image aligns to the baseline.
埋め込まれたMathMLまたは画像に対応していない利用者のプログラムの代替手段として, 代替の文字列を提供します. provides a textual alternative as a fall-back for user agents
that do not support embedded MathML or images.
このmath要素の中のcsymbol, annotation, annotation-xml要素のOpenMathコンテント辞書の位置の基となるCDの目録として働くCDグループファイルを指定します. 4.2.3 コンテントマークアップの記号 <csymbol>を参照して下さい. cdgroup属性が何も明確に指定されていない場合, このmath要素に埋め込まれた文書形式は, 基となるCDを決める方法を提供してもよいです. そうでない場合, システムは基となるCDを決めなければなりません. 特定の情報がない場合, http://www.openmath.org/cdがcsymbol, annotation, annotation-xml要素の基となるCDと仮定されます. この属性は, OpenMath協会が管理している標準のCDの集合を基としたCDです. specifies a CD group file that acts as a catalogue of CD bases for locating
OpenMath content dictionaries of csymbol, annotation, and
annotation-xml elements in this math element; see 4.2.3 Content Symbols <csymbol>. When no cdgroup attribute is explicitly specified, the
document format embedding this math element may provide a method for determining
CD bases. Otherwise the system must determine a CD base; in the absence of specific
information http://www.openmath.org/cd is assumed as the CD base for all
csymbol, annotation, and annotation-xml elements. This is the
CD base for the collection of standard CDs maintained by the OpenMath Society.
In cases where size negotiation is not possible or fails
(for example in the case of an expression that is too long to fit in the allowed width),
the overflow attribute is provided to suggest a processing method to the renderer.
Allowed values are:
数式の大きな完全な表示の一部を見せるウィンドウを提供します. 見せる部分の位置を別の場所に動かすことができるように, 必要なら水平または鉛直のスクロールバーがウィンドウに加えられます. The window provides a viewport
into the larger complete display of the mathematical
expression. Horizontal or vertical scroll bars are added to the window
as necessary to allow the viewport to be moved to a different
position.
"elide"
残った部分がウィンドウに収まるのに必要なだけ, 一部を取り除いて表示を省略します. 例えば, 大きい多項式は, 最初と最後の項とその間に+ ... +を付けて表示されるかもしれません. 進歩した描画ソフトウェアは, 省略された範囲を拡大・縮小する機能を提供するかもしれません. The display is abbreviated by removing enough of it so that
the remainder fits into the window. For example, a large polynomial
might have the first and last terms displayed with + ... +
between
them. Advanced renderers may provide a facility to zoom in on elided
areas.
"truncate"
右と下の端を切り詰めることで表示を省略します. 見る人に切り詰めたことをそれとなく示すことが推奨されます. The display is abbreviated by simply truncating it at the right and
bottom borders. It is recommended that some indication of truncation is
made to the viewer.
"scale"
数式を表示するのに使われているフォントを, ウィンドウに式全体が収まるように選びます. フォントの変更は式が大き過ぎる場合しか起こりません. 必要以上にウィンドウが大きい場合, 式は標準の大きさで大きなウィンドウの中に描画されます. The fonts used to display the mathematical expression are
chosen so that the full expression fits in the window. Note that this
only happens if the expression is too large. In the case of a window
larger than necessary, the expression is shown at its normal size
within the larger window.
Most of Presentation Markup is included in [MathML-Core].
That specification should be consulted for the precise details of displaying the elements and attributes
that are part of core when displayed in web browsers.
Outside of web browsers, 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.
Non browser-based renderers are free to use their own layout rules as long as the
renderings are intelligible.
The names used for presentation elements are suggestive of their visual layout.
However, mathematical notation has a long history of being reused as new concepts are developed.
Because of this, an element such as mfrac may not actually be a fraction and the
intent attribute should be used to provide information for auditory renderings.
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, a single row of identifiers and operators
will often be represented by multiple nested mrow elements rather than
a single mrow. For example,
typically is represented as:
<mrow><mi> x </mi><mo> + </mo><mrow><mi> a </mi><mo> / </mo><mi> b </mi></mrow></mrow>
Similarly, superscripts are attached to the full expression constituting
their base rather than to the just preceding character. This
structure permits better-quality rendering of mathematics, especially when
details of the rendering environment, such as display widths, are not
known ahead of time to the document author. It also greatly eases automatic
interpretation of the represented mathematical structures.
Certain characters are used
to name identifiers or operators that in traditional notation render the
same as other symbols or are rendered invisibly. For example, the
characters U+2146, U+2147 and U+2148 represent differential d,
exponential e and imaginary i, respectively
and are semantically distinct from the same letters used as simple variables.
Likewise, the characters U+2061, U+2062, U+2063 and U+2064
represent function application, invisible times, invisible comma and invisible plus
.
These usually render invisibly but represent significant information
that may influence visual spacing and linebreaking,
and may have distinct spoken renderings.
Accordingly, authors should use these characters (or corresponding entities)
wherever applicable.
The presentation elements are divided into two classes.
Token elements
represent individual symbols, names, numbers, labels, etc.
Layout schemata build expressions out of parts and can have
only elements as content.
These are subdivided into
General Layout,
Script and Limit,
Tabular Math and
Elementary Math schemata.
There are also a few empty elements used only in conjunction with certain layout schemata.
All individual symbols in a mathematical expression should be
represented by MathML token elements (e.g., <mn>24</mn>).
The primary MathML token element
types are identifiers (mi,
e.g. variables or function names), numbers (mn), and
operators (mo,
including fences, such as parentheses, and separators, such
as commas). There are also token elements used to represent text or
whitespace that has more aesthetic than mathematical significance
and other elements representing string literals for compatibility with
computer algebra systems.
The layout schemata specify the way in which
sub-expressions are built into larger expressions such as fraction and scripted expressions.
Layout schemata attach special meaning to the number and/or
positions of their children.
A child of a layout schema is also called
an argument of that element. As a consequence of the
above definitions, the content of a layout schema consists exactly of
a sequence of zero or more elements that are its
arguments.
Many of the elements described herein require a specific number of
arguments (always 1, 2, or 3). In the detailed descriptions of
element syntax given below, the number of required arguments is
implicitly indicated by giving names for the arguments at various
positions. A few elements have additional requirements on the number
or type of arguments, which are described with the individual
element. For example, some elements accept sequences of zero or more
arguments — that is, they are allowed to occur with no arguments
at all.
Note that MathML elements encoding rendered space do
count as arguments of the elements in which they appear.
See 3.2.7 Space <mspace/> for a discussion of the proper use of such
space-like elements.
The elements listed in the following table as requiring 1*
argument (msqrt, mstyle, merror,
mpadded, mphantom, menclose,
mtd, mscarry,
and math)
conceptually accept a single argument,
but actually accept any number of children.
If the number of children is 0 or is more than 1, they treat their contents
as a single inferredmrow formed from all their children,
and treat this mrow as the argument.
For convenience, here is a table of each element's argument count
requirements and the roles of individual arguments when these are
distinguished. An argument count of 1* indicates an inferred mrow as described above.
Although the math element is
not a presentation element, it is listed below for completeness.
要素 Element
必要な引数の数 Required argument count
引数の役割(場所によって異なる場合) Argument roles (when these differ by position)
Certain MathML presentation elements exhibit special behaviors in
certain contexts. Such special behaviors are discussed in the
detailed element descriptions below. However, for convenience, some
of the most important classes of special behavior are listed here.
Certain elements, e.g. msup, are able to
embellish operators that are their first argument. These elements are
listed in 3.2.5 Operator, Fence, Separator or Accent
<mo>, which precisely defines an embellished
operator and explains how this affects the suggested rendering rules
for stretchy operators.
In the notations familiar to most readers,
both the overall layout and the textual symbols are arranged
from left to right (LTR). Yet, as alluded to in the introduction,
mathematics written in Hebrew or in locales such
as Morocco or Persia, the overall layout is used unchanged, but
the embedded symbols (often Hebrew or Arabic) are written right to left (RTL).
Moreover, in most of the Arabic speaking world, the notation
is arranged entirely RTL; thus a superscript is still raised,
but it follows the base on the left rather than the right.
MathML 3.0 therefore recognizes two distinct directionalities:
the directionality of the text and symbols within token elements
and the overall directionality represented by Layout Schemata.
These two facets are discussed below.
The overall directionality for a formula, basically
the direction of the Layout Schemata, is specified by
the dir attribute on the containing math element
(see 2.2 The Top-Level
<math> Element).
The default is ltr. When dir=rtl
is used, the layout is simply the mirror image of the conventional
European layout. That is, shifts up or down are unchanged,
but the progression in laying out is from right to left.
For example, in a RTL layout, sub- and superscripts appear to the left of the base;
the surd for a root appears at the right, with the bar continuing over
the base to the left.
The layout details for elements whose behavior depends on directionality
are given in the discussion of the element. In those discussions, the
terms leading and trailing are used to specify a side of an object
when which side to use depends on the directionality; i.e. leading
means left in LTR but right in RTL.
The terms left and right may otherwise be safely assumed to mean left and right.
The overall directionality is usually set on the math, but
may also be switched for an individual subexpression by using the dir
attribute on mrow or mstyle elements.
When not specified, all elements inherit the directionality of their container.
3.1.5.2 素子要素における双方向の配置 Bidirectional Layout in Token Elements
The text directionality comes into play for the MathML token elements
that can contain text (mtext, mo, mi, mn
and ms) and is determined by the Unicode properties of that text.
A token element containing exclusively LTR or RTL characters
is displayed straightforwardly in the given direction.
When a mixture of directions is involved, such as RTL Arabic
and LTR numbers, the Unicode bidirectional algorithm [Bidi]
should be applied. This algorithm specifies how runs of characters
with the same direction are processed and how the runs are (re)ordered.
The base, or initial, direction is given by the overall directionality
described above (3.1.5.1 Overall Directionality of Mathematics Formulas) and affects
how weakly directional characters are treated and how runs are nested.
(The dirattribute is thus allowed on token elements to specify
the initial directionality that may be needed in rare cases.)
Any mglyph or malignmark elements appearing within
a token element are effectively neutral and have no effect
on ordering.
The important thing to notice is that the bidirectional algorithm
is applied independently to the contents of each token element;
each token element is an independent run of characters.
Other features of Unicode and scripts that should be respected
are ‘mirroring’ and ‘glyph shaping’.
Some Unicode characters are marked as being mirrored when presented in a RTL context;
that is, the character is drawn as if it were mirrored or replaced by a corresponding
character.
Thus an opening parenthesis, ‘(’, in RTL will display as ‘)’.
Conversely, the solidus (/ U+002F) is not marked
as mirrored. Thus, an Arabic author that desires the slash to be reversed
in an inline division should explicitly use reverse solidus (\ U+005C)
or an alternative such as the mirroring DIVISION SLASH (U+2215).
Additionally, calligraphic scripts such as Arabic blend, or connect
sequences of characters together, changing their appearance.
As this can have a significant impact on readability, as well as aesthetics,
it is important to apply such shaping if possible. Glyph shaping,
like directionality, applies to each token element's contents individually.
Note that for the transfinite cardinals represented
by Hebrew characters, the code points U+2135-U+2138 (ALEF SYMBOL,
BET SYMBOL, GIMEL SYMBOL, DALET SYMBOL) should be used in MathML, not the alphabetic look-alike code points.
These code points are strong left-to-right.
3.1.6 displaystyleとscriptlevel Displaystyle and Scriptlevel
So-called ‘displayed’ formulas, those appearing on a line by themselves,
typically make more generous use of vertical space than inline formulas,
which should blend into the adjacent text without intruding into
neighboring lines. For example, in a displayed summation, the limits
are placed above and below the summation symbol, while when it appears inline
the limits would appear in the sub- and superscript position.
For similar reasons, sub- and superscripts,
nested fractions and other constructs typically display in a
smaller size than the main part of the formula.
MathML implicitly associates with every presentation node
a displaystyle and scriptlevel reflecting whether
a more expansive vertical layout applies and the level of scripting
in the current context.
These values are
initialized by the math element
according to the display attribute.
They are automatically adjusted by the
various script and limit schemata elements,
and the elements
mfrac and
mroot,
which typically set displaystyle false and increment scriptlevel
for some or all of their arguments.
(See the description for each element for the specific rules used.)
They also may be set explicitly via the displaystyle and scriptlevel
attributes on the mstyle element
or the displaystyle attribute of mtable.
In all other cases, they are inherited from the node's parent.
The displaystyle affects the amount of vertical space used to lay out a formula:
when true, the more spacious layout of displayed equations is used,
whereas when false a more compact layout of inline formula is used.
This primarily affects the interpretation
of the largeop and movablelimits attributes of
the mo element.
However, more sophisticated renderers are free to use
this attribute to render more or less compactly.
The main effect of scriptlevel is to control the font size.
Typically, the higher the scriptlevel, the smaller the font size.
(Non-visual renderers can respond to the font size in an analogous way for their medium.)
Whenever the scriptlevel is changed, whether automatically or explicitly,
the current font size is multiplied by the value of
scriptsizemultiplier to the power of the change in scriptlevel.
However, changes to the font size due to scriptlevel changes should
never reduce the size below scriptminsize to prevent scripts
becoming unreadably small.
The default scriptsizemultiplier is approximately the square root of 1/2
whereas scriptminsize defaults to 8 points;
these values may be changed on mstyle; see 3.3.4 Style Change <mstyle>.
Note that the scriptlevel attribute of mstyle allows arbitrary
values of scriptlevel to be obtained, including negative values which
result in increased font sizes.
The changes to the font size due to scriptlevel should be viewed
as being imposed from ‘outside’ the node.
This means that the effect of scriptlevel is applied
before an explicit mathsize (see 3.2.2 Mathematics style attributes common to token elements)
on a token child of mfrac.
Thus, the mathsize effectively overrides the effect of scriptlevel.
However, that change to scriptlevel changes the current font size,
which affects the meaning of an em length
(see 2.1.5.2 Length Valued Attributes)
and so the scriptlevel still may have an effect in such cases.
Note also that since mathsize is not constrained by scriptminsize,
such direct changes to font size can result in scripts smaller than scriptminsize.
TEX's \displaystyle, \textstyle, \scriptstyle, and \scriptscriptstyle
correspond to displaystyle and scriptlevel
as
true and 0,
false and 0,
false and 1,
and false and 2, respectively.
Thus, math's
display=block corresponds to \displaystyle,
while display=inline corresponds to \textstyle.
MathML provides support for both automatic and manual (forced)
linebreaking of expressions to break excessively long
expressions into several lines.
All such linebreaks take place within mrow
(including inferred mrow; see 3.1.3.1 Inferred <mrow>s)
or mfenced.
The breaks typically take place at mo elements
and also, for backwards compatibility, at mspace.Renderers may also choose to place automatic linebreaks at other points
such as between adjacent mi elements or even within a token element
such as a very long mn element. MathML does not provide a means to
specify such linebreaks, but if a renderer chooses to linebreak at such a point,
it should indent the following line according to the
indentation attributes
that are in effect at that point.
Automatic linebreaking occurs when the containing math element
has overflow=linebreak
and the display engine determines that there is not enough space available to
display the entire formula. The available width must therefore be known
to the renderer. Like font properties, one is assumed to be inherited from the environment
in which the MathML element lives. If no width can be determined, an
infinite width should be assumed. Inside of an mtable,
each column has some width. This width may be specified as an attribute
or determined by the contents. This width should be used as the
line wrapping width for linebreaking, and each entry in an mtable
is linewrapped as needed.
課題304: MathML 4で非推奨となる可能性のあるプレゼンテーションMathMLの一部 Issue 304: Potential presentation MathML items to deprecate in MathML 4
Forced linebreaks are specified by using
linebreak=newline
on an mo or mspace element.
Both automatic and manual linebreaking can occur within the same formula.
Automatic linebreaking of subexpressions of mfrac, msqrt, mroot
and menclose and the various script elements is not required.
Renderers are free to ignore forced breaks within those elements if they choose.
Attributes on mo and possibly on mspace elements control
linebreaking and indentation of the following line. The aspects of linebreaking
that can be controlled are:
Where — attributes determine the desirability of
a linebreak at a specific operator or space, in particular whether a
break is required or inhibited. These can only be set on
mo and mspace elements.
(See 3.2.5.2.2 Linebreaking attributes.)
Operator Display/Position — when a linebreak occurs,
determines whether the operator will appear
at the end of the line, at the beginning of the next line, or in both positions;
and how much vertical space should be added after the linebreak.
These attributes can be set on mo elements or inherited from
mstyle or math elements.
(See 3.2.5.2.2 Linebreaking attributes.)
Indentation — determines the indentation of the
line following a linebreak, including indenting so that the next line aligns
with some point in a previous line.
These attributes can be set on mo elements or
inherited from mstyle or math elements.
(See 3.2.5.2.3 Indentation attributes.)
When a math element appears in an inline context, it may obey whatever paragraph flow
rules
are employed by the document's text rendering engine.
Such rules are necessarily outside of the scope of this specification.
Alternatively, it may use the value of the math element's overflow attribute.
(See 2.2.1 Attributes.)
3.1.7.2 改行の例 Examples of Linebreaking
次に示す例は, 強制的な改行と強制的な位置揃えを明確にしています.
The following example demonstrates forced linebreaks and forced alignment:
Note that because indentalignlast defaults to indentalign,
in the above example indentalign could have been used in place of
indentalignlast. Also, the specifying linebreakstyle='before'
is not needed because that is the default value.
3.1.8 プレゼンテーション要素の概要 Summary of Presentation Elements
These attributes include the following two attributes that are primarily intended for visual media.
They are not expected to affect the intended semantics of displayed
expressions, but are for use in highlighting or drawing attention
to the affected subexpressions. For example, a red "x" is not assumed
to be semantically different than a black "x", in contrast to
variables with different mathvariant values (see 3.2.2 Mathematics style attributes common to token elements).
素子要素の内容, 線, 根号, その他の装飾といった要素の中身を描画する際に使用する文字等の色を指定します. また, 配置要素で利用された場合, 子要素のmathcolorの既定値を定めます. Specifies the foreground color to use when drawing the components of this element,
such as the content for token elements or any lines, surds, or other decorations.
It also establishes the default mathcolor used for child elements
when used on a layout element.
要素とその子要素の領域を塗り潰すのに使用する背景色を指定します. 既定値の"transparent"は, 一般に現在描画している文章の中の背景色を透けて見えるように設定します. Specifies the background color to be used to fill in the bounding box
of the element and its children. The default, "transparent", lets the
background color, if any, used in the current rendering context to show through.
Since MathML expressions are often embedded in a textual data
format such as HTML,
the MathML renderer should inherit the
foreground color used in the context in which the MathML appears.
Note, however, that MathML (in contrast to [MathML-Core]) doesn't specify the mechanism by which
style information is inherited from the rendering environment.
See 3.2.2 Mathematics style attributes common to token elements for more details.
Note that the suggested MathML visual rendering rules do not define the
precise extent of the region whose background is affected by the
mathbackground attribute,
except that, when the content does not have
negative dimensions and its drawing region should not overlap with other
drawing due to surrounding negative spacing, should lie
behind all the drawing done to render the content, and 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 mathbackground attribute is not
defined by these rules.
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.
Token elements represent
identifiers (mi),
numbers (mn),
operators (mo),
text (mtext),
strings (ms)
and spacing (mspace).
The mglyph element
may be used within token elements
to represent non-standard symbols by images.
Preceding detailed discussion of the individual elements,
the next two subsections discuss the allowable content of
token elements and the attributes common to them.
3.2.1
素子要素の内容となる文字, <mglyph/> Token Element Content Characters, <mglyph/>
Character data in MathML markup is only allowed to occur as part of
the content of token elements. Whitespace between elements is ignored.
With the exception of the empty mspace element,
token elements can contain any sequence of zero or more Unicode characters,
or mglyph or
malignmark elements.
The mglyph element is used
to represent non-standard characters or symbols by images;
the malignmark element establishes an alignment point for use within
table constructs, and is otherwise invisible (see 3.5.5 Alignment Markers
<maligngroup/>, <malignmark/>).
Characters
can be either represented directly as Unicode character data, or indirectly via numeric
or character entity references.
Unicode contains a number of look-alike characters.
See [MathML-Notes] for a discussion of which characters are appropriate to use in which circumstance.
Token elements (other than mspace) should
be rendered as their content, if any (i.e. in the visual case, as a
closely-spaced horizontal row of standard glyphs for the characters
or images for the mglyphs in their content).
An mspace element is rendered as a blank space of a width determined by its attributes.
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. The directional characteristics of the content must
also be respected (see 3.1.5.2 Bidirectional Layout in Token Elements).
3.2.1.1 記号の表示に画像を利用する<mglyph/> Using images to represent
symbols<mglyph/>
The mglyph element provides a mechanism
for displaying images to represent non-standard symbols.
It may be used within the content of the token elements
mi, mn, mo, mtext or ms
where existing Unicode characters are not adequate.
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 and symbols 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.
Note that the glyph's src attribute uniquely identifies the mglyph;
two mglyphs with the same values for src should
be considered identical by applications that must determine whether
two characters/glyphs are identical.
The mglyph element accepts the attributes listed in
3.1.9 Mathematics attributes common to presentation elements, but note that mathcolor has no effect.
The background color, mathbackground, should show through
if the specified image has transparency.
mglyphはここに一覧にした追加の属性も持っています.
mglyph also accepts the additional attributes listed here.
画像の場所を指定します. 通常, MathML部分の基準となるURIからの相対パスとなります. Specifies the location of the image resource;
it may be a URI relative to the base-URI of the source of the MathML, if any.
字形の要求される高さを指定します. widthとheightの一方だけが与えられた場合, 画像はアスペクト比を保ったまま, 拡大・縮小されます. どちらも与えられない場合, 画像は元の大きさのまま表示されるべきです. Specifies the desired height of the glyph.
If only one of width and height are given,
the image should be scaled to preserve the aspect ratio;
if neither are given, the image should be displayed at its natural size.
画像のベースライン(訳注:欧文書体で水平の基準線で大文字の下端の位置)を通常のベースラインからどれだけずらすかを指定します. 正の値のときは画像の下端をベースラインから上げ, 負の値のときは下げます. 0の値(既定値)は, 画像のベースラインを画像の下端にすることを意味します. Specifies the baseline alignment point of the image with respect to the current baseline.
A positive value shifts the bottom of the image above the current baseline
while a negative value lowers it.
A value of 0 (the default) means that the baseline of the image is at the bottom of
the image.
字形に対する代用の名前を提供します. 指定された画像が見つからなかったり, 表示できなかったりした場合, 表示ソフトウェアはこの名前を警告メッセージや字形が見つからないという注意で利用するでしょう. この名前は, 聴覚表現ソフトウェアや記号を処理するソフトウェアで利用されるでしょう. また, 説明のために選ばれるべきでしょう. Provides an alternate name for the glyph. If the specified image can't be found or
displayed,
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.
In addition to the attributes defined for all presentation elements
(3.1.9 Mathematics attributes common to presentation elements), MathML includes two mathematics style attributes
as well as a directionality attribute
valid on all presentation token elements,
as well as the math and mstyle elements;
dir is also valid on mrow elements.
The attributes are:
素子の論理的な種類を指定します. この種類は書式の種類というわけなく, 典型的に意図した意味を伝えるものであることに注意して下さい. 下記の議論を参照して下さい. Specifies the logical class of the token. Note that this class
is more than styling, it typically conveys semantic intent; see the discussion below.
素子の中身を表示する大きさを指定します. smallまたはbigという値は, 現在のフォントサイズより小さいまたは大きいということを表します. ただし, 実際の比率は指定されておらず任されています. normalは完全性のために用意されていますが, 100%や1emと同じであり効果はありません. Specifies the size to display the token content.
The values small and big choose a size
smaller or larger than the current font size, but leave the exact proportions
unspecified; normal is allowed for completeness, but since
it is equivalent to 100% or 1em, it has no effect.
素子の中の文字の初期の方向を指定します. ltr(左から右)またはrtl(右から左). この属性は, 弱い文字(訳注:周囲の文字の方向に左右される文字で例えばかっこ"(")または中立の文字(訳注:周囲の文字の方向がどちらでも同じように表示される文字で例えば空白" ")を含む特殊な場合に必要になります. より詳しい議論については, 3.1.5.1 数式全体の方向を参照して下さい. mspaceに対しては何の効果も与えません. specifies the initial directionality for text within the token:
ltr (Left To Right) or rtl (Right To Left).
This attribute should only be needed in rare cases involving weak or neutral characters;
see 3.1.5.1 Overall Directionality of Mathematics Formulas for further discussion.
It has no effect on mspace.
The mathvariant attribute defines logical classes of token
elements. Each class provides a collection of typographically-related
symbolic tokens. Each token has a specific meaning within a given
mathematical expression and, therefore, needs to be visually
distinguished and protected from inadvertent document-wide style
changes which might change its meaning. Each token is identified
by the combination of the mathvariant attribute value
and the character data in the token element.
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 6.5 Using CSS with MathML for discussion of the
interaction of MathML and CSS.
Also, see [MathMLforCSS] for discussion of rendering MathML by CSS
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.
Most MathML renderers will probably want to rely on some degree on additional,
internal style processing algorithms.
In particular, the mathvariant attribute does not follow the CSS inheritance model;
the default value is normal (non-slanted)
for all tokens except for mi with single-character content.
See 3.2.3 Identifier <mi> for details.
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
mathvariant attribute set to sans-serif in
Helvetica or Arial. However, rendering the token in a Times Roman
font could be seriously misleading and should be avoided.
In principle, any mathvariant value may be used with any
character data to define a specific symbolic token. In practice,
only certain combinations of character data and mathvariant
values will be visually distinguished by a given renderer. For example,
there is no clear-cut rendering for a "fraktur alpha" or a "bold italic
Kanji" character, and the mathvariant values "initial",
"tailed", "looped", and "stretched" are appropriate only for Arabic
characters.
Certain combinations of character data and mathvariant
values are equivalent to assigned Unicode code points that encode
mathematical alphanumeric symbols. These Unicode code points are
the ones in the
Arabic Mathematical Alphabetic Symbols block U+1EE00 to U+1EEFF,
Mathematical Alphanumeric Symbols block U+1D400 to U+1D7FF,
listed in the Unicode standard, and the ones in the
Letterlike
Symbols range U+2100 to U+214F that represent "holes" in the
alphabets in the SMP, listed in 7.2 Mathematical Alphanumeric Symbols.
These characters are described in detail in section 2.2 of
UTR #25.
The description of each such character in the Unicode standard
provides an unstyled character to which it would be equivalent
except for a font change that corresponds to a mathvariant
value. A token element that uses the unstyled character in combination
with the corresponding mathvariant value is equivalent to a
token element that uses the mathematical alphanumeric symbol character
without the mathvariant attribute. Note that the appearance
of a mathematical alphanumeric symbol character should not be altered
by surrounding mathvariant or other style declarations.
Renderers should support those combinations of character data and
mathvariant values that correspond to Unicode characters,
and that they can visually distinguish using available font characters.
Renderers may ignore or support those combinations of character data
and mathvariant values that do not correspond to an assigned
Unicode code point, and authors should recognize that support for
mathematical symbols that do not correspond to assigned Unicode code
points may vary widely from one renderer to another.
Since MathML expressions are often embedded in a textual data
format such as HTML, 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 default 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 doesn't specify the mechanism by which
style information is inherited from the rendering environment.
If the requested mathsize 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.
Note that many MathML elements automatically change the font size
in some of their children; see the discussion in 3.1.6 Displaystyle and Scriptlevel.
3.2.2.1 MathMLの中にHTMLを埋め込む Embedding HTML in MathML
An mi element represents a symbolic name or
arbitrary text that should be rendered as an identifier. Identifiers
can include variables, function names, and symbolic constants.
A typical graphical renderer would render an mi element
as its content (see 3.2.1
Token Element Content Characters, <mglyph/>),
with no extra spacing around it (except spacing associated with
neighboring elements).
Not all mathematical identifiers are represented by
mi elements — for example, subscripted or primed
variables should be represented using msub or
msup respectively. Conversely, arbitrary text
playing the role of a term (such as an ellipsis in a summed series)
should be represented using an mi element.
It should be stressed that mi is a
presentation element, and as such, it only indicates that its content
should be rendered as an identifier. In the majority of cases, the
contents of an mi will actually represent a
mathematical identifier such as a variable or function name. However,
as the preceding paragraph indicates, the correspondence between
notations that should render as identifiers and notations that are
actually intended to represent mathematical identifiers is not
perfect. For an element whose semantics is guaranteed to be that of an
identifier, see the description of ci in
4. Content Markup.
(内容に依存. 下記の説明を参照して下さい.) (depends on content; described below)
素子の論理的な種類を指定します. 中身が単一の文字の場合を除いて, 既定値はnormal(斜体でない)です. 中身が単一の文字の場合, 既定値はitalicです. Specifies the logical class of the token.
The default is normal (non-slanted) unless the content
is a single character, in which case it would be italic.
Note that for purposes of determining equivalences of Math
Alphanumeric Symbol
characters (see 7.2 Mathematical Alphanumeric Symbols)
the value of the mathvariant attribute should be resolved first,
including the special defaulting behavior described above.
An mi element with no content is allowed;
<mi></mi> might, for example, be used by an
expression editor to represent a location in a MathML expression
which requires a term (according to conventional syntax for
mathematics) but does not yet contain one.
識別子はsinのような関数の名前を含みます. sin xのような式では, 下記に示す文字U+2061(実体afまたは実体ApplyFunction)を用いて書かれるべきです. 見えない演算子についての議論は3.2.5 演算子, かっこ, 区切り, アクセント <mo>を参照して下さい.
Identifiers include function names such as
sin. Expressions such as sin x
should be written using the character U+2061
(entity af or ApplyFunction) as shown below;
see also the discussion of invisible operators in 3.2.5 Operator, Fence, Separator or Accent
<mo>.
<mrow><mi> sin </mi><mo>⁡<!--ApplyFunction--></mo><mi> x </mi></mrow>
項として扱われるべきいろいろな文章は, 次のようにmi要素を用いて表すこともできます.
Miscellaneous text that should be treated as a term can also be
represented by an mi element, as in:
When an mi is used in such exceptional
situations, explicitly setting the mathvariant attribute
may give better results than the default behavior of some
renderers.
記号の定数の名前は, mi要素として表現されるべきです.
The names of symbolic constants should be represented as
mi elements:
An mn element represents a numeric
literal or other data that should be rendered as a numeric
literal. Generally speaking, a numeric literal is a sequence of digits,
perhaps including a decimal point, representing an unsigned integer or real
number.
A typical graphical renderer would render an mn element as
its content (see 3.2.1
Token Element Content Characters, <mglyph/>), with no extra spacing around them
(except spacing from neighboring elements such as mo).
mn elements are typically rendered in an unslanted font.
The mathematical concept of a number can be quite
subtle and involved, depending on the context. As a consequence, not all
mathematical numbers should be represented using mn; examples of mathematical numbers that should be
represented differently are shown below, and include
complex numbers, ratios of numbers shown as fractions, and names of numeric
constants.
Conversely, since mn is a presentation
element, there are a few situations where it may be desirable to include
arbitrary text in the content of an mn that
should merely render as a numeric literal, even though that content
may not be unambiguously interpretable as a number according to any
particular standard encoding of numbers as character sequences. As a
general rule, however, the mn element should be
reserved for situations where its content is actually intended to
represent a numeric quantity in some fashion. For an element whose
semantics are guaranteed to be that of a particular kind of
mathematical number, see the description of cn in
4. Content Markup.
Many mathematical numbers should be represented using presentation
elements other than mn alone; this includes
complex numbers, negative numbers, ratios of numbers shown as fractions, and
names of numeric constants.
3.2.4.4.1 数字の複雑な表現の例 Examples of complex representations of numbers
Changes to the references to match new W3C specification rules,
and to use the new W3C CSS formatting style, most notably
affecting the table of contents styling.
Modified the definition of MathML color and length valued attributes to be
explicitly based on the syntax used in [MathML-Core] which in
turn uses definitions provided by CSS3.
Remove the mode and macros attributes from <math>. These have been deprecated
since MathML 2. macros had no
defined behaviour, and mode can be
replaced by suitable use of display.
The mathml4-legacy schema makes these valid if needed for legacy applications.
The deprecated MathML 1 attributes on token elements: fontfamily,
fontweight, fontstyle, fontsize, color and background
are removed in favor of mathvariant, mathsize,
mathcolor and
mathbackground.
These attributes are also no longer valid on mstyle.
The mathml4-legacy schema makes these valid if needed for legacy applications.
In MathML table rows and cells must be explicitly marked
wih mtr and mtd. The [MathML1] required that an
implementation infer the row markup if it was omitted.
The use of malignmark has been
restricted and simplified, matching the features implemented in
existing implementations.
The groupalign attribute on table
elements is no longer supported.
The existing text on using the <semantics> element to mix
Presentation and Content MathML is maintained in the second
section, although reduced with some non normative text and
examples moved to [MathML-Notes].
MathML 3 deprecated the use of encoding and definitionURL on <semantics>. They are invalid in this
specification. The mathml4-legacy schema may be used if these
attributes need to be validated for a legacy application.
Some rewriting of the text and adjusting references as the
Media type registrations have been moved from an Appendix of this
specification to a separate document, [MathML-Media-Types].
The schema was refactored with a new mathml4-core schema
matching [MathML-Core] being used as the basis for
mathml4-presentation, and a new mathml4-legacy schema that can
be used to validate an existing corpus of documents matching [MathML3].
These new appendices collect together the syntax tables, mappings to OpenMath and rewrite rules that were
previously distributed throughout 4. Content Markup.
