数学用マークアップ言語 (MathML) バージョン 4.0
Mathematical Markup Language (MathML) Version 4.0

属性の値についてMathMLで指定された構文を説明するのに, 次に示す慣習と表記がこの文書のほとんどの属性に使用されます.

To describe the MathML-specific syntax of attribute values, the following conventions and notations are used for most attributes in the present document.

上で述べられている‘型’は, 文字列を除いて, 次に示す演算子を使用して混合した様式に組み合せることができます. 全ての属性値は, 記述されている文書の中で一重(')または二重(")引用符によって境界を決めなければなりません. この仕様書では, 二重引用符が文字列の式を記述するのによく使用されることに注意して下さい. 例としては, 上の表の5行目の"-"です.

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.

下の表でfは上の表で述べた型を意味します. 組み合せる演算子は, 優先度の高いものから低いものの順で示しています.

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:

ここで使用する表記は, MathMLの基本となる構文(A. MathMLの処理)として利用されるRelaxNGの構文表記の書式です.

The notation we have chosen here is in the style of the syntactical notation of the RelaxNG used for MathML's basic schema, A. Parsing MathML.

ソフトウェアの中には空白の標準化が一貫していないものもあるので, 最大の相互運用性のためには, 属性値の部分部分を区切るのに単独の空白文字のみを使用するのが賢明です. さらに, 属性値の中の最初と最後の空白は避けるべきです.

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.

ほとんどの数値の属性に対して, 表現可能な属性値の値の一部のみがふさわしい値です. それ以外の値は, 他で指定されていない限りエラーにはなりませんが, その代わり(描画ソフトウェア次第で)認められている範囲の最も近い値に切り上げられたり切り捨てられたりします. 認められている値の範囲は描画ソフトウェアに依存してもよいですし, MathMLでは指定していません.

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

ほとんどのプレゼンテーション要素は, 大きさ, 間隔, またはそれらに類似した特性に対して使用する, 長さを表わす値を受け入れる属性を持っています. [MathMLコア]は, [CSS-VALUES-3]で定義された<長さや百分率>の構文における長さしか受け入れません. 完全なMathMLは, 次の名前付き長さも受け入れることで, 長さの構文を拡張しています.

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:

加えて, mpaddedの属性は, 中身の元々の大きさを示す(通常のCSS単位の代わりをする)3つの疑似添え字height, depth, widthを認めています.

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は, 単位無しの数字として指定される長さの非推奨の利用も認めていました. この利用は, 参照する値の倍数として解釈されていました. この形式は, MathML 4では無効と見なされます.

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.

MathML属性に対する既定値は, 一般にこの文書の特定の要素の詳細な説明で一緒に示されています. 要素の属性の表で装飾されていない文字で示された既定値は文字列の値ですが, 下線付き太字(注釈:原文では斜体となっているものを日本語訳では下線付き太字で記載)で示された例のときは既定値がどのように計算されるかという説明です.

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.

継承すると述べられている既定値は, 3.3.4 書式の変更 <mstyle>で述べられている描画環境から引き継がれます. または, (個別に説明されている)いくつかの場合, 周囲を囲んでいる要素の他の属性の値やそれらの値の一部から引き継がれます. 使用される値は, やろうと思えば, いつも明確に指定しておくことができる値でしょう. その値は, 同じ要素の内容や属性には依存せず, 環境にのみ依存します. (しかしながら, それが何を意味しているのか, いつ使われるのかというと, それらの属性や内容に依存します.)

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

自動と述べられている既定値は, MathML描画ソフトウェアによって, 良質な描画を提供するであろう方法に従って計算されます. どのように計算されるかは, 通常MathML仕様書では指定していません. 計算される値は, やろうと思えば, いつも明確に指定しておくことができる値でしょう. ただし, その値は, 通常は要素の内容や, もしかすると要素が描画される文脈に依存するでしょう.

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.

属性の表に現れた既定値の他の下線付き太字(注釈:原文では斜体となっているものを日本語訳では下線付き太字で記載)の説明は, それぞれの属性ごとに説明しています.

Other italicized descriptions of default values which appear in the tables of attributes are explained individually for each attribute.

XMLの開始タグの中の属性値の周りに必要とされる一重引用符や二重引用符は, それぞれの要素の属性値の構文の表では示されませんが, この文書の例の中の属性値の周りには付けますし, 示されたコードの部分部分は正しいです.

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.

一般に, 継承されたり, 自動で計算されたりする属性を指定しなかった場合の効果がどうなるか, 検証する仕組みがMathMLにはないことに注意して下さい. inherited(訳注:"継承")またはautomatic(訳注:"自動")という言葉を明確に示すことは, 効果がなく一般に認められません. さらに, mstyle要素(3.3.4 書式の変更 <mstyle>)は, その子要素の表示属性の既定値を変更するために使うことができます.

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.

これらの既定値は, 属性が提供されていないときのMathMLソフトウェアの挙動についても述べていることに注意して下さい. それらの挙動は, ときどきDTDに基づいた仕様書によって委任されているXML処理プログラムによって埋め込まれる値を明確にはしていません.

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.

一般に, 文書全体の特性, または少なくとも大きな文書のその節の特性であると思われている, 数々のMathML描画の特性があります. 例としては, mathsize(数学のフォントの大きさ, 3.2.2 素子要素に共通の数学書式属性参照), または積分や総和といった演算子の添え字に設定された挙動(例えば, movablelimitsまたはdisplaystyle), もしくは行の途中での式の改行(例えば, linebreakstyle)があるでしょう. そのような属性は, 3.2 素子要素の中の様々な要素で見られます. これらの値は, 要素を含んでいる範囲の何かから継承されると思われるでしょう. ちょうど上で継承や自動の場合のMathML属性の既定値の設定について書いたとおりです. MathMLを描画する際の挙動についての汎用的な既定値を設定する第三者の資源である, MathML演算子辞書があります. 既定値の例はB. 演算子辞書で提供しています. このことは3.2.5.6.1 演算子辞書でも論じられており, 例は3.2.5.2.1 辞書に基づく属性で示しています.

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.

次の一覧で示す 1* の引数を必要としている要素(msqrt, mstyle, merror, mpadded, mphantom, menclose, mtd, mscarry, math)は, 概念上は単独の引数を受け入れますが, 実際のところ任意の数の子要素を受け入れます. 子要素の数が0個の場合, もしくは1個より大きい場合, それらの要素は, それらの中身を全ての子要素から形作られる単独の省略されたmrowとして扱い, そのmrowを引数として扱います.

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 inferred mrow formed from all their children, and treat this mrow as the argument.

例えば,

For example,

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

は次のように扱われます.

is treated as if it were

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

この機能は, MathMLのデータが, その機能がなければ必要となるたくさんのmrow要素を含まなくてもよいように(著者が同様に必要となるたくさんのmrow要素を省略してもよいように)します.

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

便利なように, それぞれの要素の引数がいくつ必要かと, 個々の引数の役割が確立している場合の役割について, 表で示します. 1* という引数の数は上で述べた省略されたmrowを意図しています. math要素はプレゼンテーション要素ではありませんが, 完全に網羅できるように下の表に挙げています.

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.

数式に対する全体の方向, 基本的に配置要素の方向は, 全体を囲っているmath要素(2.2 一番上の<math>要素参照)のdir属性によって指定されます. 既定値はltrです. dir=rtlが用いられる場合, 配置はヨーロッパの慣例的な配置に対して単純に鏡のような形になります. つまり, 字下げ等は変わりませんが, 配置の向きは右から左になります.

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.

例えば, 右から左(RTL)の配置においては, 上付き添え字と下付き添え字は, 基となる式の左に現れます. 根号は右に, 基となる式の左端まで続く上の横線を伴って現れます. 方向に依存する要素に対する配置の詳細については, 要素の説明で述べます. その説明の中で, 前に来ると後ろに来るというの用語は, 方向に依存して用いられる式の横側を指定するのに使われます. 前に来るは左から右(LTR)では左を意味しますが, 右から左(RTL)では右を意味します. 他の場合の左と右という用語は, 左と右を意味すると想定して問題ないでしょう.

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.

全体の方向は通常mathによって設定されますが, mrow要素またはmstyle要素のdir属性を利用して個々の式の部分について切り替えてもよいです. 指定されない限り, 全ての要素はそれらを囲っている要素の方向を継承します.

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.

文字の方向は, 文字を含むことができるMatthML要素(mtext, mo, mi, mn, ms)の方向と見なすことになり, その文字のユニコードの特性によって決められます. 全体として左から右(LTR)もしくは右から左(RTL)の文字を含んでいる素子要素は, 与えられた方向にまっすぐに表示されます. 右から左(RTL)のアラビア語と左から右(LTR)の数字が混合しているといった具合に方向が混合され複雑な状況にある場合, ユニコードの双方向のアルゴリズム[Bidi]が適用されます. このアルゴリズムは, どのように同じ方向の文字の並びを処理するか, どのように文字の並びを並べるのか(並べ直すのか)を指定します. 基となる, もしくは初期の方向は, 上で述べた全体の方向(3.1.5.1 数式全体の方向)によって決められ, 弱い方向の文字(訳注:周囲の文字の方向に左右される文字で例えばかっこ"(")をどのように扱うのか, どのように並びを入れ子にするのかに影響します. (そのため, dir属性は素子要素でごく稀に必要となる初期の方向を指定することができます.) 素子要素と一緒に現れる何らかのmglyph要素やmalignmark要素は, 効果的に中立で並びに影響がありません.

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 dir attribute 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.

ユニコードや文字列の考慮されるべき他の機能は, ‘鏡文字化’と‘字形の整形’です. ユニコード文字の中には, 右から左(RTL)の文脈の中での表現で鏡文字にできることが示されているものもあります. すなわち, その文字は, 鏡文字にされたり, 対応する文字で置換されたりしたかのように描かれます. よって, 始めのかっこ‘(’は, 右から左(RTL)では‘)’と表わされます. 逆に斜線(/ U+002F)は, 鏡文字にできるとされていません. よって, 行の中の割り算で反転させた斜線を表示させたいアラビア語の著者は, はっきりと反転した斜線(\ U+005C)か, 反転した割算の斜線(U+2215)といった代替文字を使用すべきです.

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.

ヘブライ文字で表現される超限数に対し, アルファベットのよく似たコードポイントではなく, MathMLではU+2135-U+2138のコードポイント(アレフ記号, べト記号, ギメル記号, ダレット記号)が使用されるべきことに注意して下さい. それらのコードポイントは, 強い(訳注:周囲の文字の方向に左右されない)左から右の文字です.

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.

MathMLは, 過度に長い式をいくつかの行に分割するために, 自動と手動(強制的)両方の式の改行の対応を提供しています. 全てのそのような改行は, mrow(省略されたmrowを含む. 3.1.3.1 省略された<mrow>参照)またはmfencedの中で行われます. 改行は典型的にmo要素の場所や, 従来との互換性からmspace要素の場所で行われます. 描画ソフトウェアは, 隣接したmi要素の間, または素子要素の中といった他の箇所で自動で改行することを選ぶかもしれません. MathMLはそのような改行を指定する手段を提供していませんが, 描画ソフトウェアがそのような場所で改行することを選ぶのであれば, そのような場所でも効果のある字下げの属性によって次の行を字下げすべきです.

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.

囲っているmath要素がoverflow=linebreakで, 描画エンジンが式全体を表示するのに十分な空間がないと判断したとき, 自動の改行が起こります. よって利用可能な幅が描画ソフトウェアに知られていなければなりません. 書式の特性のように, 改行の特性はMathML要素が存在する環境から継承されるとしています. 幅が決められなかった場合, 無限の幅であると見なされます. mtableの中で各列はいくらか幅を持っています. この幅は属性として指定され, 内容によって決まります. この幅は, 改行のためには行全体の幅として使われるべきで, mtableの各要素は必要に応じて幅を持っています.

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.

強制的な改行は, mo要素またはmspace要素のlinebreak=newlineを利用して指定されます. 自動と手動の改行は, 両方とも同じ数式の中で起こっても良いです.

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.

mfrac, msqrt, mroot, mencloseの中の式や様々な添え字の要素の自動的な改行は不要です. 描画ソフトウェアは, それらの要素の中に強制的な改行がある場合, その改行を無視しても良いです.

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.

mo要素や, 場合によってはmspace要素の属性は, 改行や次の行の字下げを制御します. 制御可能な改行の性質は次のとおりです.

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:

• 場所 ― 属性は, 特定の演算子や空白での改行が望ましいか, 特に改行が必要か禁止か決めます. これらの属性は, mo要素やmspace要素でのみ設定できます. (3.2.5.2.2 改行の属性を参照して下さい.)

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

• 演算子の表示/位置 ― 改行されたときに, 属性は, 行の最後か, 次の行の最初か, その両方の場所か, どこに演算子が現れるべきか決めます. これらの属性は, mo要素で設定されるか, mstyle要素またはmath要素から継承されるかします. (3.2.5.2.2 改行の属性を参照して下さい.)

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

• 字下げ ― 属性は, 次の行を前の行のどこかと揃えるための字下げすを含め, 改行に続く行の字下げの方法を決めます. これらの属性は, mo要素で設定されるか, mstyle要素またはmath要素から継承されるかします. (3.2.5.2.3 字下げの属性を参照して下さい.)

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

math要素が行の中の文脈で現れたとき, math要素は文章の描画エンジンによって段落を描くどんな決まりを用いられようと, その決まりに従うでしょう. そのような決まりは必然的にこの仕様書の対象外です. 代わりに, math要素のoverflow属性の値を用いるでしょう. (2.2.1 属性を参照して下さい.)

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

これらに加えて, mglyph要素が, 標準でない記号を画像として表現するのに, 素子要素と一緒に使用されてもよいです.

Additionally, the mglyph element may be used within Token elements to represent non-standard symbols as images.

プレゼンテーション要素は, [MathMLコア]で指定された全ての共通の属性も受け入れます.

Presentation elements also accept all the Global Attributes specified by [MathML-Core].

次の2つの属性を含むこれらの属性は, 特に視覚的な分野を想定したものです. これらの属性は, 表示された式の意図している意味に影響を与えないものとされていますが, 式の一部を強調したり, 注意を引いたりするのに利用されます. 例えば, 異なるmathvariantを持つ変数とは対照的に, 赤い"x"は黒い"x"と意味が違うとは考えません(3.2.2 素子要素に共通の数学書式属性参照).

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

MathMLの式は, HTMLのような文章データフォーマットによく埋め込まれることから, MathML描画ソフトウェアは, MathMLが現れた場所の文章で利用されている色を継承すべきです. しかしながら, ([MathMLコア]と対照的に)MathMLは描画環境から書式情報を継承する仕組みを特定していないことに注意して下さい. 詳細については3.2.2 素子要素に共通の数学書式属性を参照して下さい.

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.

提案されているMathMLの視覚的描画の決まりは, 次の場合を除いて, mathbackground属性の影響を受ける, 背景の領域の正確な範囲を定義していないことに注意して下さい. それは, 内容が負の領域を持っておらず, 周囲との間隔が負であることによって描画領域が他の描画領域と重なるべきでない場合です. その場合の領域は内容を表示する描画領域全ての背後となるべきですが, 周囲を取り囲んでいる式を表示する描画領域の前面には来るべきです. mathbackground属性の影響が及ぶ領域の範囲において, 周囲との間隔が負であることにより描画領域が重なった場合の影響は, MathMLの描画の決まりによって定義されてはいません.

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.

MathMLは, 7.4 MathMLと他の言語を組合せるで述べているように, 他の言語と組合せることができます. 仕様書は, MathMLに他のフォーマットを埋め込むのに, mtext要素の子要素や, 式の中で埋め込む役割を果たすのに適切な他の葉要素の子要素に, 追加の要素を認めるようMathML構文を拡張しました(3.2.3 識別子 <mi>, 3.2.4 数字 <mn>, 3.2.5 演算子, かっこ, 区切り, アクセント <mo>参照). 方向, フォントサイズ, その他のフォントの属性は, それらを含む葉要素の文字に使用される属性を継承すべきです(3.2.2 素子要素に共通の数学書式属性参照).

MathML can be combined with other formats as described in 7.4 Combining MathML and Other Formats. The recommendation is to embed other formats in MathML by extending the MathML schema to allow additional elements to be children of the mtext element or other leaf elements as appropriate to the role they serve in the expression (see 3.2.3 Identifier <mi>, 3.2.4 Number <mn>, and 3.2.5 Operator, Fence, Separator or Accent <mo>). The directionality, font size, and other font attributes should inherit from those that would be used for characters of the containing leaf element (see 3.2.2 Mathematics style attributes common to token elements).

HTMLの内容を含むmtextの中にSVGを埋め込んだ例を示します.

Here is an example of embedding SVG inside of mtext in an HTML context:

<mtable>
 <mtr>
  <mtd>
   <mtext><input type="text" placeholder="what shape is this?"/></mtext>
  </mtd>
 </mtr>
 <mtr>
  <mtd>
   <mtext>
    <svg xmlns="http://www.w3.org/2000/svg" width="4cm" height="4cm" viewBox="0 0 400 400">
     <rect x="1" y="1" width="398" height="398" style="fill:none; stroke:blue"/>
     <path d="M 100 100 L 300 100 L 200 300 z" style="fill:red; stroke:blue; stroke-width:3"/>
    </svg>
   </mtext>
  </mtd>
 </mtr>
</mtable>

mi要素は, 識別子として表示されるべき記号の名前や何らかの文字列を表します. 識別子には, 変数, 関数名, 定数の記号が含まれます. 典型的な画像描画ソフトウェアは, mi要素を(隣接する要素に関連する空白以外の)周囲の空白を取り除いて, その中身として描画します(3.2.1 素子要素の内容となる文字, <mglyph/>参照).

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

数学の識別子全てがmi要素によって表現されるわけではありません. 例えば, 添え字が付いたり, プライムが付いたりした変数は, それぞれmsubやmsupを用いて表現されるべきです. 逆に, (級数の和における省略といった)項の役割をする何らかの文字列は, mi要素を利用して表現すべきです.

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.

miはプレゼンテーション要素であることを強調しておきます. そのこと自体は, 要素の中身が識別子として描画されることを単に表しています. 大半の場合, miの中身は実際のところ, 変数や関数名といった数学の識別子を表すでしょう. しかしながら, 前の段落で示したように, 識別子として描画されるべき表記と, 実際に数学の識別子を表すことを意図している表記との対応は完全ではありません. 要素の意味が識別子そのものであることが保証されている要素については, 4. コンテントマークアップのciの説明を参照して下さい.

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.

mi要素は, 3.2.2 素子要素に共通の数学書式属性で一覧にした属性を持っています. ただし, 1つだけ既定値が異なります.

mi elements accept the attributes listed in 3.2.2 Mathematics style attributes common to token elements, but in one case with a different default value:

数学用英数字記号文字(8.2 数学用英数字記号参照)と等しいことを決定するために, mathvariant属性の値は, 上で述べた特別な既定の挙動を含め, 最初に解決すべきです.

Note that for purposes of determining equivalences of Math Alphanumeric Symbol characters (see 8.2 Mathematical Alphanumeric Symbols) the value of the mathvariant attribute should be resolved first, including the special defaulting behavior described above.

mn要素は, 数値の文字列や数値の文字列として描画されるべき他のデータを表します. 一般に言って, 数値の文字列は数字の列で, 場合によっては小数点を含み, 符号の付かない整数または実数を表します. 典型的な画像描画ソフトウェアは, mn要素を(moのような隣接する要素との間の空白以外の)周囲の空白を取り除いて, その中身を描画します(3.2.1 素子要素の内容となる文字, <mglyph/>参照). mn要素は典型的に, 傾いていない字形で描画されます.

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.

"数字"の数学上の概念は, 完全にあいまいで複雑な内容になるでしょう. 結果として, 全ての数学の数字が, mnを用いて表されるべきということではありません. 違った表現とされるべき数学の数字の例は下記に示すもので, 複素数, 分数として表される数字の比率, 数値の定数の名前を含みます.

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.

反対に, mnはプレゼンテーション要素であるので, mnの中身が何らかの文字を含んでいることが望ましい場合がわずかにあります. 文字列としての数字の特に標準的なコード化によれば, 中身が数字として明確に解釈されない場合であっても, mnは単に数値の文字列として描画されるべきです. 一般的な決まりとして, mn要素は、中身が何らかの方法で実際に数値的な量を表そうとしてる状況に当てられるべきです. 要素の意味が数学の数字の特定の種類であることが保証されている要素については, 4. コンテントマークアップのcnの説明を参照して下さい.

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.

mn要素は, 3.2.2 素子要素に共通の数学書式属性で一覧にした属性を持っています.

mn elements accept the attributes listed in 3.2.2 Mathematics style attributes common to token elements.

多くの数学の数字は, mn単独ではなく, プレゼンテーション要素を使用して表されるべきです. それらの数字は, 複素数, 負の数, 分数として表される数字の比率, 数値の定数の名前を含みます.

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.

<mrow>
  <mn> 2 </mn>
  <mo> + </mo>
  <mrow>
    <mn> 3 </mn>
    <mo> &#x2062;<!--InvisibleTimes--> </mo>
    <mi> ⅈ </mi>
  </mrow>
</mrow>

<mfrac> <mn> 1 </mn> <mn> 2 </mn> </mfrac>

<mrow><mo>-</mo><mn>2</mn></mrow>

<mi> π </mi>

<mi> ⅇ </mi>

mo要素は, 演算子や演算子として描画すべきものを表します. 一般に, 数学の演算子の表記の慣習は大変複雑です. MathMLは, mo要素の描画するときの挙動を特定する比較的洗練された仕組みを提供しています. 結果として, MathMLにおいて演算子として描画されるべきものの一覧は, 普通の感覚では数学の演算子ではない数学表記を含んでいます. 中間や前や後ろに置かれる普通の演算子の他に, その一覧は, 大かっこや丸かっこや絶対値の縦棒といった囲い文字, コンマやセミコロンといった区切り, 記号の上の横棒やチルダといった数学のアクセントを含みます. "演算子"という用語を, この章では広い意味で演算子を表すものに使用します.

An mo element represents an operator or anything that should be rendered as an operator. In general, the notational conventions for mathematical operators are quite complicated, and therefore MathML provides a relatively sophisticated mechanism for specifying the rendering behavior of an mo element. As a consequence, in MathML the list of things that should render as an operator includes a number of notations that are not mathematical operators in the ordinary sense. Besides ordinary operators with infix, prefix, or postfix forms, these include fence characters such as braces, parentheses, and absolute value bars; separators such as comma and semicolon; and mathematical accents such as a bar or tilde over a symbol. We will use the term "operator" in this chapter to refer to operators in this broad sense.

典型的な視覚的描画ソフトウェアは全てのmo要素を, 後で詳しく述べる, 属性によって決められた要素の周りの空白と一緒に, その中身として描画します(3.2.1 素子要素の内容となる文字, <mglyph/>参照). MathML文字集合に対応する完全なフォントを利用できない描画ソフトウェアは, mo要素を描画するのに, その中身の文字を正確に選ばない場合があってもよいです. 例えば, <mo> ≤ </mo>は端末に<=として描画されるかもしれません. しかしながら, 一般的な決まりとして, 描画ソフトウェアは可能な限り文字通りにmo要素の中身を描画しようと試みるべきです. すなわち, <mo> ≤ </mo>と<mo> &lt;= </mo>は異なって描画されるべきです. 前者は小なりまたは等しい記号を表す単独の文字として描画されるべきで, 後者は2つの文字の文字列<=として描画されるべきです.

Typical graphical renderers show all mo elements as the content (see 3.2.1 Token Element Content Characters, <mglyph/>), with additional spacing around the element determined by its attributes and further described below. Renderers without access to complete fonts for the MathML character set may choose to render an mo element as not precisely the characters in its content in some cases. For example, <mo> ≤ </mo> might be rendered as <= to a terminal. However, as a general rule, renderers should attempt to render the content of an mo element as literally as possible. That is, <mo> ≤ </mo> and <mo> &lt;= </mo> 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 <=.

mo要素の鍵となる特徴は, 属性の既定値が後で説明する演算子辞書によって状況に応じて決まることです. 特に, stretch, symmetric, accentの既定値は通常演算子辞書によって決まるので, 個々のmo要素について指定する必要がありません.

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

数学の演算子はmo要素単独で表現されるものばかりでなく, (例えば)周囲の上付き添え字で装飾されたmo要素として表現されることもあることに注意して下さい. このことは後で詳しく説明します. 逆に, プレゼンテーション要素としてmo要素は, 中身となる文章が演算子として標準的に解釈されない場合も含め, 何らかの文章を含むことができます. 例としては3.2.6 文章 <mtext>の文章と数字を混ぜるの議論を参照して下さい. また, 特定の数学演算子として意味を持つことが保証されているMathMLコンテント要素の定義については, 4. コンテントマークアップを参照して下さい.

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

また, 改行は3.1.7 式の改行で論じたように, 通常演算子の(地域の慣習によって前もしくは後いずれかの)場所で行われることに注意して下さい. そのため, moは指定された演算子で改行が望ましいかコード化する属性を持ち, さらに改行がその演算子で行われた場合の演算子の扱いや字下げを説明する属性を持ちます.

Note also that linebreaking, as discussed in 3.1.7 Linebreaking of Expressions, usually takes place at operators (either before or after, depending on local conventions). Thus, mo accepts attributes to encode the desirability of breaking at a particular operator, as well as attributes describing the treatment of the operator and indentation in case a linebreak is made at that operator.

mo要素は, 3.2.2 素子要素に共通の数学書式属性で一覧にした属性やここで一覧にした追加の属性を持っています. 演算子の表示は数学において大変重要なので, mo要素はたくさんの数の属性を持っています. それらは次の3つの小節で説明しています.

mo elements accept the attributes listed in 3.2.2 Mathematics style attributes common to token elements and the additional attributes listed here. Since the display of operators is so critical in mathematics, the mo element accepts a large number of attributes; these are described in the next three subsections.

ほとんどの属性は, 取り囲んでいるmstyle要素, math要素, 含まれている文書, 3.2.5.6.1 演算子辞書から既定値を受け取ります. 継承するとなっている値がはっきりとmo要素, mstyle要素, math要素で与えられていない場合や, 対象のmo要素が演算子辞書の中から見つからなかった場合, かっこ内に示された既定値が使用されます.

Most attributes get their default values from an enclosing mstyle element, math element, from the containing document, or from 3.2.5.6.1 The operator dictionary. When a value that is listed as inherited is not explicitly given on an mo, mstyle element, math element, or found in the operator dictionary for a given mo element, the default value shown in parentheses is used.

ここで示す伝統的な数学表記で見えない演算子は, 単に何も書かないのではなくmo要素と一緒に特定の文字(または, 実体参照)を用いて表現すべきです. 見えない演算子として用いられる文字は次のとおりです.

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

<mrow>
  <mi> f </mi>
  <mo> &#x2061;<!--ApplyFunction--> </mo>
  <mrow>
    <mo> ( </mo>
    <mi> x </mi>
    <mo> ) </mo>
  </mrow>
</mrow>

<mrow>
  <mi> sin </mi>
  <mo> &#x2061;<!--ApplyFunction--> </mo>
  <mi> x </mi>
</mrow>

<mrow>
  <mi> x </mi>
  <mo> &#x2062;<!--InvisibleTimes--> </mo>
  <mi> y </mi>
</mrow>

<msub>
  <mi> m </mi>
  <mrow>
    <mn> 1 </mn>
    <mo> &#x2063;<!--InvisibleComma--> </mo>
    <mn> 2 </mn>
  </mrow>
</msub>

<mrow>
  <mn> 2 </mn>
  <mo> &#x2064; </mo>
  <mfrac>
    <mn> 3 </mn>
    <mn> 4 </mn>
  </mfrac>
</mrow>

mo要素に対する典型的な描画の挙動は, 他のMathMLの素子要素よりも複雑です. そのため, mo要素に対する描画の決まりをこの分割された小節で説明しています.

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

全てのMathMLの描画の決まりと同じように, これらの決まりは必要条件というより提案であることに注意して下さい. 下記の説明は, 様々な描画属性の意図する効果を可能な限り明確にするために提供されています. ブラウザの実装での演算子に対する詳細な配置の決まりは, MathMLコアで示されています.

Note that, like all rendering rules in MathML, these rules are suggestions rather than requirements. The description below is given to make the intended effect of the various rendering attributes as clear as possible. Detailed layout rules for browser implementations for operators are given in MathML Core.

4つの属性(stretchy, symmetric, maxsize, minsize)が, (場合によっては装飾された)演算子が他の要素の大きさに合うように引き伸ばされるがどうか, どのように引き伸ばされるかを管理しています. 演算子がstretchy=trueという属性を持っているならば, 演算子(すなわち, 内容の個々の文字)は下に示す, フォントやフォント描画システムによって課されている制約である, 引き伸ばされる際の決まりに従います. 実際のところ, 典型的な描画ソフトウェアは, 文字の少数の集合だけを引き伸ばすことができ, 文字の大きさの一部の集合を生み出すことだけが完全に可能です.

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

MathMLは, 特定の文字や演算子を(水平または縦の)どちらの方向に引き伸ばすのか指定する準備はありません. むしろ, stretchy=trueのとき, その文字にとってどちらの方向に引き伸ばすのも可能で適切であれば, どちらの方向にも引き伸ばすべきです. 描画ソフトウェアが文字を引き伸ばすことが可能ならば, 文字をどちらの方向に引き伸ばす方が適切かを判断するのは, 描画ソフトウェア次第です. ほとんどの文字は典型的な描画ソフトウェアによってほぼ一方向にしか引き伸ばされませんが, 描画ソフトウェアの中には斜めの矢印といったある特定の文字を両方の方向に独立して引き伸ばせるものもあります.

There is no provision in MathML for specifying in which direction (horizontal or vertical) to stretch a specific character or operator; rather, when stretchy=true it should be stretched in each direction for which stretching is possible and reasonable for that character. It is up to the renderer to know in which directions it is reasonable to stretch a character, if it can stretch the 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.

minsize属性とmaxsize属性は, (方向を限定せずに)引き伸ばす限度を決めます. 2つの属性は, 演算子自身の方向または引き伸ばす方向の通常の大きさの倍数, もしくは単位を用いた絶対量で与えられます. 例えば, 文字がmaxsize=300%であるならば, その文字の(引き伸ばす前の)通常の大きさの3倍を超えて伸ばすことはできません.

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

symmetric属性は, 文字の中心の軸の上の高さと下の深さを(高さと深さの両方をそれぞれの最大にすることで)等しくさせるかどうか管理します. symmetric=falseと設定されている状況の例としては, 正方行列でない行列の掛け算でよく用いられる, 軸で揃えられていない行列の周りのかっこが挙げられます. この場合, 行列を覆うようにかっこを引き伸ばそうとしたとき, かっこを対称に引き伸ばすと, 行列の片方の端からかっこが突き出すことになります. symmetric属性は文字が縦方向に引き伸ばされる場合に適用されます(他の方向は無視されます).

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

引き伸ばされるmo要素が(この節の前の方で定義したように)装飾されているのならば, 核となるmo要素は装飾された演算子全体の内容に基づく大きさに引き伸ばされます. すなわち, 装飾が無い場合と同じように引き伸ばされます. 例えば, (典型的に演算子辞書によって引き伸ばされるものと設定される)次に示す例のかっこは, 互いに同じ大きさに引き伸ばされ, さらに同じ縦方向の間隔を保つでしょう.

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

<mrow>
  <munder>
    <mo> ( </mo>
    <mo> _ </mo>
  </munder>
  <mfrac>
    <mi> a </mi>
    <mi> b </mi>
  </mfrac>
  <mover>
    <mo> ) </mo>
    <mo> ‾ </mo>
  </mover>
</mrow>

このことは, 後で述べる引き伸ばすときの決まりがmo要素そのものにではなく, 装飾された演算子全体の内容に適用されなければならないことを意味していることに注意して下さい.

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

<mrow>
  <mo maxsize="100%">(</mo>
  <mfrac>
    <msup><mi>a</mi><mn>2</mn></msup>
    <msup><mi>b</mi><mn>2</mn></msup>
  </mfrac>
  <mo maxsize="100%">)</mo>
</mrow>

<mrow>
  <mi> x </mi>
  <munder>
    <mo> → </mo>
    <mtext> maps to </mtext>
  </munder>
  <mi> y </mi>
</mrow>

mtext要素は, 文章自体として描画されるべき任意の文章を表すのに使われます. 一般に, mtext要素は, 注釈の文章を示すよう意図されています.

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

明確に表記上の役割を定義されている文章は, miやmoを用いてより適切に記述されるであろうことに注意して下さい.

Note that text with a clearly defined notational role might be more appropriately marked up using mi or mo.

mtext要素は描画できる空白を含めるのに使うことができます. すなわち, 周囲の要素の場所を変更しようとする見えない文字を含められます. 視覚的でない媒体において, そのような文字は, 聴覚表現ソフトウェアでの, 読む間隔を伸ばしたり短くしたりする効果や, 効果的なリズムを生み出すといった代わりの効果を持とうとします. なお, 2.1.7 入力された空白を縮小するを参照して下さい.

An mtext element can also contain renderable whitespace, i.e. invisible characters that are intended to alter the positioning of surrounding elements. In non-graphical media, such characters are intended to have an analogous effect, such as introducing positive or negative time delays or affecting rhythm in an audio renderer. However, see 2.1.7 Collapsing Whitespace in Input.

mtext要素は, 3.2.2 素子要素に共通の数学書式属性で一覧にした属性を持っています.

mtext elements accept the attributes listed in 3.2.2 Mathematics style attributes common to token elements.

また, 空白のような要素の正式なグループ化についての警告は3.2.7 空白 <mspace/>を, そのような要素を微調整のために利用することについての警告は[MathMLメモ]を参照して下さい.

See also the warnings about the legal grouping of space-like elements in 3.2.7 Space <mspace/>, and about the use of such elements for tweaking in [MathML-Notes].

mspace空要素は, 属性により設定された何らかの望ましい大きさの空白を表します. また, mspace要素は, 視覚的な描画ソフトウェアに改行の提案をするのにも利用できます. 属性の既定値は, 典型的に描画に何の影響も与えないように選ばれていることに注意して下さい. よって, mspace要素は一般に, 明確に指定された1つ以上の属性値と一緒に利用されます.

An mspace 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 mspace element is generally used with one or more attribute values explicitly specified.

後で書く空白のような要素の正式なグループ化についての警告と, [MathMLメモ]の中の微調整に対するそのような要素の利用についての警告に注意して下さい. 空白として描画できる他の要素, すなわちmtext, mphantom, maligngroupについても参照して下さい.

Note the warning about the legal grouping of space-like elements given below, and the warning about the use of such elements for tweaking in [MathML-Notes]. See also the other elements that can render as whitespace, namely mtext, mphantom, and maligngroup.

下に一覧にした属性に加えて, mspace要素は3.2.2 素子要素に共通の数学書式属性で述べた属性を持っています. ただし, mathvariantとmathcolorは何の効果もなく, mathsizeは大きさを決める属性の単位(2.1.5.2 長さの値の属性参照)の解釈にのみ影響することに注意して下さい. mspaceは, 3.2.5.2.3 字下げの属性で述べた字下げの属性も持っています.

In addition to the attributes listed below, mspace elements accept the attributes described in 3.2.2 Mathematics style attributes common to token elements, but note that mathvariant and mathcolor have no effect and that mathsize only affects the interpretation of units in sizing attributes (see 2.1.5.2 Length Valued Attributes). mspace also accepts the indentation attributes described in 3.2.5.2.3 Indentation attributes.

改行は, 元はと言えばMathML2でmspaceに対して指定されました. しかしながら, 改行や字下げのよりたくさんの制御が, MathML 3でmoに加えられました. mspaceにおける改行は, MathML 4では非推奨です.

Linebreaking was originally specified on mspace in MathML2, but much greater control over linebreaking and indentation was add to mo in MathML 3. Linebreaking on mspace is deprecated in MathML 4.

数々のMathMLプレゼンテーション要素が, 典型的に空白として描画され, それらが現れても式の数学的意味に影響を与えないという点で空白のような要素です. 結果として, それらの要素は, 他のMathMLの式の中で多少異なる機能を持っています. 例えば, 空白のような要素は, 3.2.5 演算子, かっこ, 区切り, アクセント <mo>で示されたmoに対して提案された描画の決まりにおいて特別に扱われます. 次に示すMathML要素が空白のような要素であるとされています.

A number of MathML presentation elements are space-like in the sense that they typically render as whitespace, and do not affect the mathematical meaning of the expressions in which they appear. As a consequence, these elements often function in somewhat exceptional ways in other MathML expressions. For example, space-like elements are handled specially in the suggested rendering rules for mo given in 3.2.5 Operator, Fence, Separator or Accent <mo>. The following MathML elements are defined to be space-like:

• mtext要素, mspace要素, maligngroup要素, malignmark要素

  an mtext, mspace, maligngroup, or malignmark element;

• 直下の式全てが空白のような要素であるmstyle要素, mphantom要素, mpadded要素

  an mstyle, mphantom, or mpadded element, all of whose direct sub-expressions are space-like;

• 最初の引数が存在し, その引数が空白のような要素だった場合のsemantics要素

  a semantics element whose first argument exists and is space-like;

• maction要素が対象としている式があり, その式が空白のような要素だった場合のmaction要素

  an maction element whose selected sub-expression exists and is space-like;

• 直下の式全てが空白のような要素であるmrow要素

  an mrow all of whose direct sub-expressions are space-like.

mphantomは, その中身が空白のような要素でない場合, 自動的には空白のような要素と定義されていないことに注意して下さい. これは, 演算子の間隔が隣接する要素が空白の要素であるかどうかによって影響を受けるためです. mphantom要素は第一に式を揃えることの助けとなることを意図しているので, mphantomに隣接する要素は, mphantomと同じ大きさの空白とではなく, mphantomの中身に隣接しているかのように動作すべきです.

Note that an mphantom is not automatically defined to be space-like, unless its content is space-like. This is because operator spacing is affected by whether adjacent elements are space-like. Since the mphantom element is primarily intended as an aid in aligning expressions, operators adjacent to an mphantom should behave as if they were adjacent to the contents of the mphantom, rather than to an equivalently sized area of whitespace.

既存のMathMLの式に空白のような要素やmphantom要素を挿入する著者は, 式の要素が特定の数を引数と必要としていたり, 引数の場所の違いによって解釈を変えたりする場合に, 挿入する要素が引数と見なされることに注意すべきです.

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

したがって, そのような要素に挿入された空白のような要素は, グループ化するためのmrowを挿入することによって隣接する引数とグループ化すべきです. 例えば, 上付き添え字の基となる式の左端で縦に揃えようとする場合, 次の式は不当です.

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

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

なぜなら, msupはちょうど2つの引数を持つからです. 正しい表現は次のとおりです.

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

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

[MathMLメモ]の中の微調整についての警告についても参照して下さい.

See also the warning about tweaking in [MathML-Notes].

ms要素は, 数式処理システムやプログラミング言語を含む他のシステムで解釈されるであろう式の中の文字列を表すのに使われます. 通常, 文字列は周りに余計な空白を加えず, 二重引用符で囲まれて表示されます. 3.2.6 文章 <mtext>で説明しているように, 数式の中に埋め込まれる通常の文章はmtext, 場合によってはmoまたはmiで記述されるべきで, msによって絶対に記述されるべきではありません.

The ms element is used to represent string literals in expressions meant to be interpreted by computer algebra systems or other systems containing programming languages. By default, string literals are displayed surrounded by double quotes, with no extra spacing added around the string. As explained in 3.2.6 Text <mtext>, ordinary text embedded in a mathematical expression should be marked up with mtext, or in some cases mo or mi, but never with ms.

msでコード化される文字列は, アスキー文字というより, 文字, mglyph, malignmarkから構成されています. 例えば, <ms>&amp;</ms>は単独の文字&から成る文字列を表しており, <ms>&amp;amp;</ms>は最初の文字が&である5つの文字から成る文字列を表しています.

Note that the string literals encoded by ms are made up of characters, mglyphs and malignmarks rather than ASCII strings. For example, <ms>&amp;</ms> represents a string literal containing a single character, &, and <ms>&amp;amp;</ms> represents a string literal containing 5 characters, the first one of which is &.

ms要素の内容は, まずは左右の引用符, もしくは個々の空白文字以外の空白を含む, 素子の中の特定の文字を視覚的にエスケープして描画されるべきです. その意図は, 見る人にその式が文字列であることを伝え, ちょうどその内容の文字を見せるためです. 例えば, <ms>double quote is "</ms>は"double quote is \""と描画されるでしょう.

The content of ms elements should be rendered with visible escaping of certain characters in the content, including at least the left and right quoting characters, 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, <ms>double quote is "</ms> might be rendered as "double quote is \"".

全ての素子要素と同様に, msは2.1.7 入力された空白を縮小するにある決まりによって, 内容の中の空白を切り取ったり縮小したりします. そのため, 内容の中で残したい空白は, その節で説明されている方法でコード化すべきです.

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

ms要素は3.2.2 素子要素に共通の数学書式属性で一覧にした属性に加えて次の属性を持ちます.

ms elements accept the attributes listed in 3.2.2 Mathematics style attributes common to token elements, and additionally:

mrow要素は, 任意の数の式を一緒にグループ化するのに使われます. グループは, 通常, その中で演算子として働く1つ以上のmoと, それらの被演算子となる1つ以上の式から構成されます.

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

様々な要素が, 引数がmrow要素に囲まれているかのように, 自動的に引数を扱います. 省略されたmrowについての議論は, 3.1.3 必要な引数を参照して下さい. コンマで区切られた引数を含むmrowを効果的に形作ることができるmfenced(3.3.8 かっこの組で囲まれた式<mfenced>)も参照して下さい.

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

mrow要素は, 典型的にその引数を水平の行として視覚的に描画します. 引数が左から右(LTR)を向いた文脈の中にあるときは左から右に, 右から左(RTL)を向いた文脈の中にあるときは右から左に描画します. dir属性は特定のmrowの方向を指定するのに利用できます. 指定されない場合, 文脈から方向を継承します. 聴覚ソフトウェアでは, 引数は, 引数の聴覚表現の一連のものとして聞き取れるように表現されるでしょう. mo要素に対して提案されている描画の決まりの3.2.5 演算子, かっこ, 区切り, アクセント <mo>における説明は, 演算子とその被演算子の間の全ての水平の間隔が, それらを含んでいるmrow要素の描画によってではなく, mo要素(または, もっと一般に装飾された演算子)の描画によって加えられることを前提にしています.

mrow elements are typically rendered visually as a horizontal row of their arguments, left to right in the order in which the arguments occur within a context with LTR directionality, or right to left within a context with RTL directionality. The dir attribute can be used to specify the directionality for a specific mrow, otherwise it inherits the directionality from the context. For aural agents, the arguments would be rendered audibly as a sequence of renderings of the arguments. The description in 3.2.5 Operator, Fence, Separator or Accent <mo> of suggested rendering rules for mo elements assumes that all horizontal spacing between operators and their operands is added by the rendering of mo elements (or, more generally, embellished operators), not by the rendering of the mrows they are contained in.

MathMLは, 自動と手動両方の式の改行(すなわち, 過度に長い式をいくつかの行へ分割すること)に対応しています. 全てのそのような改行は, 文書の中でmrowが明確に記述されていようと, 省略されていようと(3.1.3.1 省略された<mrow>参照), mrowの中で起こります. 改行の制御は他の要素の属性を通じて効果的に行われるにも関わらずです(3.1.7 式の改行参照).

MathML provides support for both automatic and manual linebreaking of expressions (that is, to break excessively long expressions into several lines). All such linebreaks take place within mrows, whether they are explicitly marked up in the document, or inferred (see 3.1.3.1 Inferred <mrow>s), although the control of linebreaking is effected through attributes on other elements (see 3.1.7 Linebreaking of Expressions).

mrow要素は, 3.1.9 プレゼンテーション要素に共通の数学属性で一覧にした属性に加えて下に示した属性を持ちます.

mrow elements accept the attribute listed below in addition to those listed in 3.1.9 Mathematics attributes common to presentation elements.

式の中の式は, 文書の著者によって式の数学上の解釈と同じ方法でグループ化されるべきです. すなわち, 式の根底にある構文ツリー構造によるべきです. 特に, 演算子とそれらの数学上の引数は単一のmrowの中に現れるべきです. 複数の演算子が1つのmrowに直接現れるのは, それらの演算子が綴じ込まれた引数に一緒に影響すると(構文上の感覚で)考えられる場合のみです. 例えば, 単独のかっこでくくられた項とかっこ, つながっている関係する演算子, +と-で区切られた一連の項の場合です. 正確な決まりは後で示します.

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

適切なグループ化はいくつかの意味を持っています. グループ化は, 効果的な間隔の取り方で表示を改善します. また, より聡明な改行と字下げを考慮します. そして, 数式処理システムや聴覚表現ソフトウェアによるプレゼンテーション要素の意味の起こり得る解釈を単純化します.

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

不適切はグループ化は, ときどき最善でない表示となったり, よく純粋な視覚的描画とは別の解釈を難しく, もしくは不可能にします. にもかかわらず, mrowを用いた式の任意のグループ化がMathML構文では認められています. すなわち, 描画ソフトウェアは, 適切なグループ化の決まりが守られていると思うべきではありません.

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

mfrac要素は分数に使用されます. また, 二項係数やルジャンドル記号といった分数のようなものを記述するのにも利用されます. mfracの構文は次のとおりです.

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

<mfrac> 分子 分母 </mfrac>
<mfrac> numerator denominator </mfrac>

mfrac要素は, 分子と分母に対し, displaystyleをfalseに設定するか, もし既にfalseであるならscriptlevelを1つ増やします. (3.1.6 displaystyleとscriptlevelを参照して下さい.)

The mfrac element sets displaystyle to false, or if it was already false increments scriptlevel by 1, within numerator and denominator. (See 3.1.6 Displaystyle and Scriptlevel.)

mfrac要素は, 3.1.9 プレゼンテーション要素に共通の数学属性で一覧にした属性に加えて下に示した属性を持ちます. 分数の線は, もし指定されていたなら, mathcolorで指定された色を使って描かれるべきです.

mfrac elements accept the attributes listed below in addition to those listed in 3.1.9 Mathematics attributes common to presentation elements. The fraction line, if any, should be drawn using the color specified by mathcolor.

太い線(例えば, linethickness="thick")は, 入れ子になった分数で使用されるでしょう. 値が"0"のときは, 二項係数のように線無しで描画されます.

Thicker lines (e.g. linethickness="thick") might be used with nested fractions; a value of "0" renders without the bar such as for binomial coefficients.

右から左(RTL)の文脈において, 分子は前に来て(右に行き), 分母は後ろに来て(左に行き), 対角線は右から左に向かって斜めに上がります(明瞭な説明については3.1.5.1 数式全体の方向参照). この形式が確立された慣習にも関わらず, 普遍的とはされていません. 上で示した斜線が右から左(RTL)の文脈で決められた状況で, mrowの中のmoといった代わりのマークアップが使用されるべきかもしれません.

In a RTL directionality context, the numerator leads (on the right), the denominator follows (on the left) and the diagonal line slants upwards going from right to left (see 3.1.5.1 Overall Directionality of Mathematics Formulas for clarification). Although this format is an established convention, it is not universally followed; for situations where a forward slash is desired in a RTL context, alternative markup, such as an mo within an mrow should be used.