as opposed to the default rendering
.
概要: 数学用マークアップ言語 (MathML) バージョン 2.0
前: 2 MathML の基礎
次: 4 コンテンツ・マークアップ
3 プレゼンテーション・マークアップ
3.1 導入
3.1.1 プレゼンテーション・マークアップで表現できるもの
3.1.2 この章で使用する用語
3.1.3 必要な引数
3.1.4 扱いが特殊な要素
3.1.5 双方向レイアウト
3.1.6 プレゼンテーション要素のまとめ
3.2 トークン要素
3.2.1 トークン要素における MathML 文字
3.2.2 トークン要素に共通な数学用スタイル属性
3.2.3 識別子 (mi)
3.2.4 数 (mn)
3.2.5 演算子、囲い文字、区切り文字、アクセント (mo)
3.2.6 Text (mtext)
3.2.7 Space (mspace)
3.2.8 String Literal (ms)
3.2.9 Adding new character glyphs to MathML
(mglyph)
3.3 General Layout Schemata
3.3.1 Horizontally Group Sub-Expressions
(mrow)
3.3.2 Fractions (mfrac)
3.3.3 Radicals (msqrt, mroot)
3.3.4 Style Change (mstyle)
3.3.5 Error Message (merror)
3.3.6 Adjust Space Around Content
(mpadded)
3.3.7 Making Sub-Expressions Invisible (mphantom)
3.3.8 Expression Inside Pair of Fences
(mfenced)
3.3.9 Enclose Expression Inside Notation
(menclose)
3.4 Script and Limit Schemata
3.4.1 Subscript (msub)
3.4.2 Superscript (msup)
3.4.3 Subscript-superscript Pair (msubsup)
3.4.4 Underscript (munder)
3.4.5 Overscript (mover)
3.4.6 Underscript-overscript Pair
(munderover)
3.4.7 Prescripts and Tensor Indices
(mmultiscripts)
3.5 Tables and Matrices
3.5.1 Table or Matrix
(mtable)
3.5.2 Row in Table or Matrix (mtr)
3.5.3 Labeled Row in Table or Matrix
(mlabeledtr)
3.5.4 Entry in Table or Matrix (mtd)
3.5.5 Alignment Markers
3.6 Enlivening Expressions
3.6.1 Bind Action to Sub-Expression (maction)
この章では、MathML の「プレゼンテーション」要素について定めています。 プレゼンテーション要素は、数学的な記法のレイアウト上の構造について記述することができます。
プレゼンテーション要素は、従来の数学表記における「コンストラクター」に対応します。つまり、従来の数学表記の中ですべての数式を構成する、記号と式による基本的な構造に対応しています。 従来の視覚上の表記は非常に大切ですから、ここで出てくる要素が表す表記上の構造については、視覚的な言葉で説明されます。 ただし、音声発話装置にも十分な情報を含むように設計されているという点では、要素は視覚的な構造に完全に従属しているわけではありません。 これらの要素の属性の中は、視覚的なメディアでしか意味をなさないものもありますが、ほとんどの属性は音声メディアでも同様の方法で扱うことができます (たとえば、時間的な「間」と水平方向の間隔を対応づけることによって)。
メディア依存のレンダリングや各自のスタイルの好みを可能にするため、MathML のプレゼンテーション要素はレンダリングの方法を示唆しているに過ぎません (つまり、必須ではありません)。 この仕様書では、視覚的なレンダリング規則を詳細に提案するところがありますが、しかし MathML レンダラーはわかりやすければ独自の規則を利用して構いません。
表題・セクション・段落がテキスト文書の高度な構文構造を表現するのと同様に、プレゼンテーション要素は式の構文構造を表現します。
従って、たとえば「x + a / b」のような変数と演算子の列も、必ずしもただ一つの mrow 要素 (引数を水平方向の列としてレンダリングする要素) によって表されるのではなく、式を構成する入れ子式の副式にそれぞれ対応した複数の mrow 要素によって表されます。
つまり、この場合は下のようになります:
<mrow>
<mi> x </mi>
<mo> + </mo>
<mrow>
<mi> a </mi>
<mo> / </mo>
<mi> b </mi>
</mrow>
</mrow>
また、上付文字は、先行する単一の文字に付くのではなく、基底を構成する式全体に対して付きます。 この構造によって、文書制作者が表示幅などのレンダリング環境の詳細を把握できない時でも、より高画質な数学のレンダリングが可能となります。 また、表現された数学構造の機械的に解釈することも容易になります。
MathML の文字の中には、演算子や変数の名前に用いられる物があり、従来の数学表記の中で他の記号 ⅆ や ⅇ や ⅈ のような記号や、⁢ や ⁡ や ⁣ のように不可視な演算子と同様にレンダリングされていました。
これらは、それぞれ別の読み上げられ方をしたり、改行や空白の効果が異なる場合があるので、表記上の別々な記号やオブジェクトだと考えられ、従って、特別な実体参照によって適切に表現されるべきです。
たとえば、視覚的に「f(x)'」と表現される式は、英語では一般に、単に「f x」ではなく「f of x」と読まれます;
これは MathML では ⁡ 演算子を「f」の後に用いることで表現可能で、この場合音声では「of」とレンダリングされるでしょう。
MathML の実体の完全なリストは 第6章「文字、実体とフォント」 で説明されています。
この章を読む前に、MathML の構文と文法について 第2.4節「MathML の構文と文法」 を読むことを強く推奨します。 この第2.4節は、MathML の表記と規約について重要な情報を含んでいます。 この第3章では特に、読者が基本的な XML 用語について 第2.4.2節「XML 構文入門」を、属性値の表記と規約について述べられている 第2.4.4節「MathML の属性値」を、それぞれ読んでいることを前提としています。
この節の残りでは、この章で使用する MathML 独自の用語と規約について紹介しています。
プレゼンテーション要素は大きく 2 種類に分類することができます。
トークン要素は個々の記号、名前、数、ラベルなどを表現するものです。
トークン要素は、一般に、文字のみを本体として含むことができますが、例外として、垂直方向の位置揃えを表現する malignmark 要素、mglyph 要素と、実体参照があります。
レイアウトスキーマは、数式の部品をまとめて大きな数式に構成するもので、空白 (無視される) を除いては要素のみを本体として含みます。
その他に、他のレイアウトスキーマと共に用いられる空要素があります。
式中の個々の「記号」は MathML のトークン要素によって表現されます。
基本的な MathML のトークン要素は、識別子 (たとえば変数や関数名)、数、演算子 (括弧のような囲い文字や、カンマのような区切りも含む) を表すものです。
数学的な重要性というよりは審美的な重要性のためにテキストや空白を表現するトークン要素もありますし、自動数式システムとの互換性を持たせるために「文字列リテラル」を表現する要素もあります。
ただし、トークン要素は単一で意味を持つ「記号」(名前、数、ラベル、数学記号など) を表現するとは要っても、その記号が 1 つ以上の文字から成り立つことがあるということに注意して下さい。
たとえば、sin と 24 は、単一のトークン要素によって、それぞれ <mi>sin</mi> や <mi>24</mi> と表現されます。
従来の数学表記では、式は副式から再帰的に構築され、究極的には一つ一つの記号から構成されていました。 それぞれのパーツは、表記上の構造の小さな集合をグループ化ないし配置してできていました。 この方法は、「式のコンストラクター」として考えることができます。 MathML でも、式は同様に構築され、レイアウトスキーマが副式から式を構成する方法を指定します。 ここでは、従来の数学の植字において副式から式を形成していたレイアウト方法と、それぞれのレイアウトスキーマを対応づけて、用語が導入されています。
この章で出てくる特殊な要素、そして要素間の関係は、以下の通り: プレゼンテーション要素 は、MathML の要素で、この章で定義するものです。 この要素は 第3.1.6節「プレゼンテーション要素のサマリー」 に一覧を挙げています。 コンテンツ要素 は、MathML の要素で、第4章「コンテンツ・マークアップ」 で定義しています。 コンテンツ要素は、第4.4節「コンテンツ・マークアップ要素」 に一覧があります。
MathML の 式(expression) とは、空要素 none や mprescripts のような例外を含む、プレゼンテーション要素の単一のインスタンス、あるいは、プレゼンテーション要素の本体として許されているコンテンツ要素 (これについては 第5.2.4章「プレゼンテーション・マークアップ中のコンテンツ・マークアップ」 で述べられています) の単一のインスタンスです。
式 E の 副式(sub-expression) とは、E の本体の一部を構成するすべての MathML の表現のことで、それは 直接的 あるいは 間接的、すなわちそれが E の「子」であるかどうかに依りません。
レイアウト・スキーマは、その子の数や位置に特別な意味を与えますので、レイアウト・スキーマの子も要素の 引数 と呼ばれます。 上記のように定義した結果として、レイアウト・スキーマの本体には、その子となる0個以上の要素の列が含まれることになります。
ここで説明する要素のほとんどは、特定の数の引数 (常に 1, 2, ないし 3) を必要とします。 下にある要素の構文に関しての詳しい説明の中では、必要とされる引数の数は引数の位置や名前から暗に知ることができます。 引数の数や種類にそれ以上の要請をする要素はそれほど多くはありません (それぞれの要素について説明されています) 。 0 個以上の引数を受け付ける要素がありますが、それは、全く引数が無くても構わないということです。
空白を描画するための MathML の要素が、含まれる要素の引数として見なされることに注意してください。
このような空白を扱う要素の正しい利用法については、第3.2.7節「空白 (mspace)」 を参照してください。
mrow下の表に挙げた要素で、必要な引数が 1* とされているもの (msqrt, mstyle, merror, menclose, mpadded, mphantom, mtd と math) は、実際には引数がいくつあっても構いません。
しかし、引数が 0 個の時、あるいは 1 個より多い時 (i.e. 2個以上の時)、その引数すべてから形成される mrow 要素を一つ含むものと推定 (inferred) して扱われます。
なお、math 要素はプレゼンテーション要素ではありませんが、下の一覧では完全を期すために追加されています。
たとえば
<mtd> </mtd>
というコードは、以下のように扱われます:
<mtd> <mrow> </mrow> </mtd>
また、
<msqrt> <mo> - </mo> <mn> 1 </mn> </msqrt>
というコードは、以下のようになります:
<msqrt>
<mrow>
<mo> - </mo>
<mn> 1 </mn>
</mrow>
</msqrt>
この機能のおかげで、MathML データは多くの mrow 要素を含む必要が無く、データ制作者は本来必要なこの要素を省略することができるのです。
レンダリングの方法を考える際、上で挙げた要素については、この方法で引数全体から形成される mrow 要素をただ一つの式として本体に持つ、と考えることができます。
ただし、これらの要素は、通常は一つの式を処理する考えられるので、下の表では引数の数は 1* と記述してあります。
ここで、便利のために、それぞれの要素で必要な引数の数を表に纏めてあります。
それぞれの引数の役割が決まっている場合は、その役割も書いてあります。
引数の数が 1* となっているものは、既に述べたように mrow 要素を推定するということを意味しています。
| 要素 | 必要な引数の数 | 引数の意味 (位置によって意味が変わる場合) |
|---|---|---|
mrow |
0 以上 | |
mfrac |
2 | 分子 分母 |
msqrt |
1* | |
mroot |
2 | 基底 index |
mstyle |
1* | |
merror |
1* | |
mpadded |
1* | |
mphantom |
1* | |
mfenced |
0 以上 | |
menclose |
1* | |
msub |
2 | 基底 下付き文字 |
msup |
2 | 基底 上付文字 |
msubsup |
3 | 基底 下付文字 上付文字 |
munder |
2 | 基底 下ルビ (underscript) |
mover |
2 | 基底 上ルビ (overscript) |
munderover |
3 | 基底 下ルビ 上ルビ |
mmultiscripts |
1 以上 | base
(subscript superscript)*
[<mprescripts/>
(presubscript presuperscript)*] |
mtable |
0 or more rows | 0 個以上の mtr 要素または mlabeledtr 要素 |
mlabeledtr |
1 以上 | ラベルと 0 個以上の mtd 要素 |
mtr |
0 以上 | 0 個以上の mtd 要素 |
mtd |
1* | |
maction |
1 以上 | actiontype 属性に依存 |
math |
1* |
MathML のプレゼンテーション要素の中には、文脈によっては特別な役目を果たすものがあります。 そういった特別な動作については、下の詳しい要素の説明の中で述べていますが、 便利のために、ここで特別な動作のうち重要な種類について挙げておきます。
要素の中には空白と考えて良いものがあり、第3.2.7節「空白 (mspace)」 で定義されています。
この定義は、mo 要素 (第3.2.5節「演算子、囲い文字、区切り文字、アクセント (mo)」) についてのレンダリング規則に影響があります。
msup のような要素では、1番目の引数となる演算子を修飾することができます。
このような要素は 第3.2.5節「演算子、囲い文字、区切り、アクセント (mo)」 に一覧で挙げ、明確に「修飾される演算子」(embellished operator)を定義し、これが伸縮可能な演算子のレンダリング規則にどう影響するか説明しています。
要素の中には、1つ以上の引数を指定すると、その引数を「推定の mrow」(inferred mrow) の引数とみなすものがあります。
これについては 第3.1.3節「必要な引数」 を参照してください。
MathML 1.x では、mtable 要素は mtr 要素をその引数の親として推定し、mtr 要素は mtd 要素をその引数の親として推定していました。
MathML 2.0 では、mtr 要素と mtd 要素は必ず明示的に書かねばなりません。
ただし、過去との互換性のため、レンダラーは mtr 要素と mtd 要素を推定することが望まれます。
「双方向レイアウト」という用語は、アラビア語やヘブライ語のような一部の言語では文字が右から左に向かって書かれ、これらの言語の中に左から右に向かって書かれた数字やアルファベットを混ぜると 1 つの行ないし段落の中に 2 種類の方向が生じてしまうという状況を示しています。
一般的なテキストに関して言えば、Unicode の仕様によって双方向アルゴリズムが定められています [Bidi]。 このアルゴリズムは、「バッキングストア」(訳注: バッファの一種) 中の文字の順番が論理順序 (つまり、発音ないしタイプされる順) にあるとみなし、 文字属性や他のディレクティブに従って表示の際に文字がどのように記録されるかを決定します。 HTML, CSS, XSL, SVG ではこのアルゴリズムを採用し、マークアップやスタイルシートによって表示順を制御します。
数式中の双方向レイアウトは、テキスト中のそれに比べてより複雑になります。 これは、数学のレイアウトが2次元的な性質を持っていることや、 空間的な位置関係で表記の意味を伝えることが原因です。 また、右から左へ書く言語の中でもあまり双方向レイアウトを利用しないため、 双方的なレイアウトに関する約束事が確立していないことも原因となっています。
こうした状況を踏まえ、MathML 2.0 では Unicode 双方向アルゴリズムのうち、 限られたもののみを採用しました。 この節の残りでは、このアルゴリズムについて説明します。
MathML のテキストを含むことができるトークン要素 (mtext, mo, mi, mn and ms) では、
その内容が視覚的にレンダリングされる際には Unicode 双方向アルゴリズムの implicit part が採用されます (つまり文字属性に基づいて並べ替えられます) [Bidi]。
ここで、基本となる方向は left-to-right です。
Unicode 双方向アルゴリズムの implicit part は、1文字のみしかない場合や、right-to-left の指向性の強い文字 (つまりアラビア語やヘブライ語などの文字) がない場合、left-to-right レイアウトと同一です。
right-to-left の指向性の強い文字をレンダリングする必要がない場合、 アプリケーションは Unicode 双方向アルゴリズムの適用が要請されません。
超限濃度 (transfinite cardinal) を表現するヘブライ文字に、コード番号 U+2135 から U+2138 (ALEF SYMBOL, BET SYMBOL, GIMEL SYMBOL, DALET SYMBOL) が使われることに注意してください。 これらは、左から右への強い指向性を持ちます。
MathML 2.0 は、数式において、右から左へ記述するレイアウトや、 双方向レイアウトについては扱っていません。 サポートされるのは、左から右へのレイアウトのみです。 数式の右から左へのレイアウトについては、 MathML の将来的なバージョンで扱われることでしょう。
mi |
識別子 |
mn |
数 |
mo |
演算子、囲い文字、区切り文字 |
mtext |
テキスト |
mspace |
空白 |
ms |
文字列リテラル |
mglyph |
MathML に新しい文字グリフを加える |
mrow |
任意の数の副式を水平方向にグループ化する |
mfrac |
2つの副式から1つの分数を作成する |
msqrt |
2乗根を作る (radical without an index) |
mroot |
form a radical with specified index |
mstyle |
スタイルを変更する |
merror |
プリプロセッサからの構文エラーメッセージを enclose する |
mpadded |
本体の周囲の空白を調整する |
mphantom |
場所を確保し、しかし本体を不可視にする |
mfenced |
1対の囲い文字で本体を囲む |
menclose |
enclose content with a stretching symbol such as a long division sign. |
msub |
下付き文字を設定する |
msup |
上付文字を設定する |
msubsup |
下付・上付文字の組を設定する |
munder |
下ルビ(underscript)を設定する |
mover |
上ルビ(overscript)を設定する |
munderover |
下ルビ・上ルビの組を設定する |
mmultiscripts |
attach prescripts and tensor indices to a base |
mtable |
表、あるいは行列 |
mlabeledtr |
表ないし行列のラベルや式番号のついた行 |
mtr |
表ないし行列の行 |
mtd |
表ないし行列の1つのエントリー |
maligngroup および
malignmark |
字寄せのマーカー |
maction |
bind actions to a sub-expression |
プレゼンテーション・マークアップにおけるトークン要素は、 数学表記の最小の単位に対応し、意味を伝えるためのものです。 トークンとは、テキストにおける単語に類似していると言えます。 しかし、数学表記は正確かつ記号的な性質を持っているため、 テキストデータでは個々の単語を特別にマークアップしたりスタイルを付けたりする必要はありませんが、 MathML マークアップにおいてはトークン要素の種類やプロパティがとても重要です。
トークンは、一般に一つの数学記号を表現する単一の文字から構成されますが、 その他にも、関数名など、複数の文字からなるトークンもあります。 さらに、従来の数学表記では植字上のプロパティによって記号を区別して使ってきた (e.g. リー代数には Fraktur 書体の 'g' を用いたり、ベクトルの表記には太字の 'x' を用いたりします) ので、スタイル・メカニズムが植字上のプロパティを遵守して意味が損なわれないように注意しなければなりません。 従って MathML においては、文字、トークン、記号の植字上のプロパティは、 それぞれ密接な関係があります。
MathML マークアップの中では、文字データはトークン要素の本体としてのみ存在できます。
唯一の例外は、要素間のホワイトスペースで、これは無視されます。
トークン要素は、任意の 0個以上の Unicode 文字列を含むことができます。
特に、本体が空のトークンが許されており、一般には不可視に、つまり通常のトークン要素の周囲の空白以外に幅を持たずに、描画する際に用います。
空要素 mspace と mglyph は、この限りではありません。
mspace 要素の幅は、属性値に依存しています。
mglyph 要素は、その属性が表現する文字を用いて描画します。
すべての Unicode 文字データはトークン要素の本体として有効ですが、
MathML 2.0 は、名前突きの Unicode 3.2 文字からなる特別なサブセットを区別し、
これを文書中で〈MathML 文字〉と呼んでいます。
MathML 文字の完全な一覧は、第6章「文字、実体とフォント」 で定義しています。
MathML 文字は、直接 Unicode 文字データで表現されることもありますし、
数値文字参照ないし文字実体参照の形で間接的に表現されることもあります。
数値文字参照と文字実体参照の利点と欠点についての議論に関しては、第6章「文字、実体とフォント」 を参照してください。
新しい数学用の文字、つまり既存の MathML 文字の非標準的なグリフは、mglyph 要素によって表現されます。
mglyph 要素以外には、malignmark 要素がそれ以外で唯一トークンの本体として認められます。
詳しくは 第3.5.5節「アラインメント・マーカー」 を参照してください。
mspace および mglyph 以外のトークン要素は、
この2要素の本体としてレンダリングされるべき
(i.e. 視覚的な場合で言えば、本体における文字中で、
密接した標準的なグリフの水平方向の列として描画されるべき)
です。
レンダリングのアルゴリズムは、
後述の数学スタイル属性によって実現されるべきで、
それぞれのトークン要素の種類によって異なる規則ないし属性によって
周囲の空白を調整するべきです。
数学で用いられる記号の大部分は、1文字の識別子で、 主に数式中で変数名として使われます。 異なった書体の文字は、それぞれ異なった記号として扱われます。 たとえば、Fraktur書体の 'g' という記号はリー代数を表し、 ローマン体での 'g' は、それに対応する リー群を表します。 このような文字主体の記号は、字間や線種など、 テキスト本文中の文字とは変えて植字されます。 どんな些細なスタイルの変換でも数式中における意味を変えてしまうおそれがあるため、 これらの文字のスタイル・メカニズムは特別に扱う必要があります。
このような理由から、Unicode 3.1 では、900以上もの数学用の記号文字が導入されました。 この新しい文字は、SMP (Secondary Multilingual Plane) に格納されています。 詳しくは、第6章「文字、実体、フォント」 を参照してください。 MathML 2.0 で許容される文字は、この正式な Unicode データですので、ツールやフォントが広く利用されるようになります。私たちは、これこそが文字用の記号を記述する最も優れた方法だと考えています。
SMP文字のサポートは広く用いられるでしょう。しかし、マークアップによって BMP (Basic Multilingual Plane) 文字のみを使う代替的なエンコーディングもまた提供される必要があります。
MathML 2.0 では、BMP 文字データの組み合わせによるトークン要素、mathvariant属性、そして SMP Math Alphanumeric Symbol 文字を含むトークンの間の対応付けを定義しています。
SMP 文字を受け付けるプロセッサー・アプリケーションは、対応するBMPや属性の組み合わせも同様に扱わねばなりません。
次の節では mathvariant 属性についてより詳しく述べています。また、完全な技術説明は 第6.2.3節「数学用英数字記号の文字」 で提供されています。
MathML 2.0 には、新しく4つの 数学用スタイル mathematics style 属性が導入されました。
これらの属性は、mspace と mglyph を除くすべてのプレゼンテーショントークン要素で有効です。これは mstyle 要素も例外ではありません。
4つの属性は以下の通りです:
| 名前 | 値 | 標準値 |
|---|---|---|
| mathvariant | normal | bold | italic | bold-italic | double-struck | bold-fraktur | script | bold-script | fraktur | sans-serif | bold-sans-serif | sans-serif-italic | sans-serif-bold-italic | monospace | normal (<mi>は除く) |
| mathsize | small | normal | big | number v-unit | 継承される |
| mathcolor | #rgb | #rrggbb | html-color-name | 継承される |
| mathbackground | #rgb | #rrggbb | html-color-name | 継承される |
(属性値の表記についての用語と表記については、第2.4.4節「MathML 属性値」 を参照のこと)
数学用スタイル属性では、トークン要素の論理クラスが定められます。 それぞれのクラスは、与えられた数式の中で意味を持つ印刷関係の記号トークンの集合に対応させるするものです。 従って、他のスタイルとは視覚的に区別され、文書全体のスタイルの変更によってうっかり意味が変わってしまうことがないよう保護される必要があります。
CSS が利用できる環境で MathML がレンダリングされる際、 数学用スタイル属性はCSSスタイル規則用のあらかじめ定められたセレクターとして 見ることができます。 より詳しい議論とCSSスタイルシートの例については、第7.1.5節「CSSとMathMLの共用」 および 付録G「MathML用CSSスタイルシートの例」 を参照してください。 CSS が利用できない場合、他の論理クラスとの視覚的な区別は、描画アプリケーション内部のスタイル機構に依存します。
理論的には、レンダラーは数学用のスタイル属性と特定の描画プロパティとのマッピングを自由に行うことができます。しかしながら、実際には、数学用スタイル属性名とその値は、植字上のプロパティを示唆するものであり、レンダラーはそれらの自然な解釈をできる限り尊重すべきです。たとえば、mathvariant 属性をもつトークンを Helvetica や Arial のような sans-serif 書体に設定することは合理的ですが、Times Roman フォントでレンダリングすることは非常に誤解を招きやすいので、そのような実装は避けるべきです。
ただし、mathvariant 属性値の自然な解釈は特定の文字に対してのみ有意義である、という問題があります。たとえば、'fraktur'書体のαや、太斜体の漢字は明瞭でわかりやすいレンダリングができません。一般的に、明確に解釈できるのは、SMP Math Alphanumeric Symbol の文字に限定されます。
従って、mathvariant 属性を SMP Math Alphanumeric Symbol 対応する文字に適用する場合は、スタイルシート制作者やプリケーション開発者は、その明確な植字上の解釈をできる限り尊重することが求められますが、それ以外の場合に mathvariant 属性の及ぼす効果については、レンダラーに依存します。
たとえばレンダラーは ∑ (非 SMP 対応文字) を含むトークンについて、mathvariant 属性が bold ないし bold-fraktur に設定される時に太字フォントで表示し、fraktur に設定された時に標準の Roman 書体で表示することができます。
この例からわかるように、制作者は mathvariant 属性を非 SMP 対応文字に対して用いるべきではありません。なぜなら、それは意味がない上に、どのようにレンダリングされるか予想不可能だからです。
最後に、特殊な例として扱われなければならない mathvariant 属性についての冗長性の問題があります。
BMP 文字データ (詳細は 第6.2.3節「Mathematical Alphanumeric Symbols Characters」を参照のこと) の一部の文字を含む mi 要素に mathvariant 属性を用いる場合、レンダリングの結果が SMP 文字を含む mi 要素に mathvariant 属性をもたないものと視覚的に区別できなくなることがあります。
そこで、MathML 2.0 では、これらの2つの表示を等価なものとして扱うよう処理アプリケーションに要求します。
これは、検索や等価性の試験をサポートするアプリケーションための問題を念頭に置いたものです。
第 2.4.5 節「すべての MathML 要素に共通する属性」で述べられているとおり、トークン要素にはスタイルシート機構との互換性のために id, xref, class および style 属性が許容されています。
しかし、CSS を用いる場合には若干の注意が必要です。
式の意味を変えてしまうような視覚的な効果を生むために CSS を用いることは、特に避けるべきです。というのも、MathML は非 CSS 環境で用いられることがあるからです。
同様に、任意の文書全体にわたるスタイルの変換によって、数式に対し意味が変わるなどの影響が及ばないことが保証されるよう注意されるべきです。
しばしば MathML 式は XHTML のようなテキストデータ形式の中に埋め込まれますので、 周囲の文字とMathMLは、レンダリングが互換になるよう、フォントの大きさといったレンダリング属性を共有しなければなりません。 この理由のために、テキストのレンダリングに影響を及ぼすほとんどの属性値は、周囲のレンダリング環境を継承します。これは上記の表の「標準値」の列に示されています。 (周囲のテキストと MathML がブラウザーとプラグインのように 別々のソフトウェアによってレンダリングされる場合も、周囲の文字のベースラインの高さなどといった MathML 属性として定義されていない付加情報とともに MathML レンダラーにレンダリング環境が提供されることが重要です。) ただし、MathML 2.0 はスタイル情報がレンダリング環境から継承されるメカニズムについては定めていないことに注意してください。 たとえば、あるブラウザーのプラグインは CSS 継承メカニズムを完全に利用して CSS プロパティーを完全に解析してレンダリングするかも知れませんし、他のアプリケーションではルートノードのスタイル環境のみを考慮して内部のスタイル継承ルールを利用するかも知れません。
ほとんどの MathML レンダラーは、おそらく付加的な内部スタイル処理アルゴリズムが必要となるでしょう。
特に、mathvariant 属性の継承は CSS モデルとは異なります。
この属性の標準値は mi 以外のすべてのトークンに対して normal (非斜体) であり、mi トークンについて、標準値はトークンの中身の文字数に依存します。
(廃止された fontslant 属性もまたこのような挙動を示しました。)
詳しくは 第3.2.3節「識別子 (mi)」 を参照してください。
下に挙げる MathML 1.01 のスタイル属性は、MathML 2.0 では廃止されました。CSS をサポートするレンダリング環境では、これらの属性に対応する描画プロパティは CSS を用いて制御することが望ましいです。しかし通常は、上で述べたように、これらの描画プロパティをどんな方法であれ直接的に操作することは避けるべきです。
もしも新しい数学用スタイル属性と、それに競合する廃止属性の両方が同時に指定される場合、新しい数学用スタイル属性の値が使われるべきです。たとえば
<mi fontweight='bold' mathvariant='normal'> a </mi>
という指定は、通常の太さのフォントで描画され、
<mi fontweight='bold' mathvariant='sans-serif'> a </mi>
というマークアップは、通常の太さの sans serif 書体で描画されるべきです。
<mi fontweight='bold' mathvariant='fraktur'> a1 </mi>
一般に SMP Math Alphanumeric Symbol 文字ではない '1' には fraktur が適応されませんが、この例では mathvariant 属性によって fontweight 属性がオーバーライドされています。
数字の Fraktur 書体のない環境では、これを Fraktur 書体の 'a' と Roman 書体の '1' で描画するレンダラーが多いでしょう。
廃止された 1.01 のスタイルの属性値は、継承関係についても、新しい数学用スタイル属性によってオーバーライドされます。従って
<mstyle fontstyle='italic'> <mi mathvariant='bold'> a </mi> </mstyle>
というマークアップは、太字の直立な (イタリックではない) フォントで描画されるでしょう。
しかし一方で、MathML 1.01 の属性は依然として役に立ちます。 MathML 1.01 属性は、数学レイアウトに必要な直接描画プロパティに対応するので、 MathML のレイアウト規則とアルゴリズムを記述するのにとても便利だからです。 この理由から、そして後方互換性のために、この章で説明している MathML のレンダリング規則は、引き続き MathML 1.01 のスタイル属性を用いた描画プロパティの用語で記述されています。
廃止された属性は以下の通り:
| 名 | 値 | 標準値 |
|---|---|---|
| fontsize | number v-unit | inherited |
| fontweight | normal | bold | inherited |
| fontstyle | normal | italic | normal (except on <mi>) |
| fontfamily | string | css-fontfamily | inherited |
| color | #rgb | #rrggbb | html-color-name | inherited |
fontsize 属性は、望み通りのフォントサイズを定めます。
v-unit は、垂直長さの単位です
(第2.4.4.3節「CSS互換の属性」を参照してください)。
植字の世界では、フォントサイズを指定するための単位として、一般に pt (ポイント) が用いられます。
もし表示中のフォントでは表示できないフォントサイズが要求された時、レンダラーはもっとも可読性が高く、できうる限り高品質なレンダリングを実現できる方法を選んで、近づけるべきです。
MathML 要素の多くは、子要素について自動的に fontsize を調節します; mstyle の節の scriptlevel の議論を参照してください。→第3.3.4節「スタイルの変更 (mstyle)」
fontfamily 属性の値は、MathML のレンダラーが利用できるフォントの名前であって、レンダラーがそれぞれの方法でフォントを選ぶことができます;
この属性に指定できる値とその意味は、レンダラーやその使用される環境に依存し、MathML によって特定されるものではありません。
(ただし下の css-fontfamily についての注意書きを参照してください)
(レンダラーがフォントを名前で検索するメカニズムは、大文字小文字を区別することがある、ということに注意しましょう)
もし fontfamily の値がレンダラーによって認識できないものであっても、それは MathML のエラーと解釈してはいけません。
むしろレンダラーは、要求されたフォントに最も近い適切なフォントを使用するか、その属性を無視して値の設定をなかったことにするべきです。
fontfamily 属性の使用は、必ずしもすべての MathML のレンダラーで利用可能ではありません。
特に、ASCII 文字ではない MathML 文字への参照を実現する目的で fontname 属性を使ってはいけません (例えば、一般の文字を非ASCIIグリフに対応させているような Symbol フォントの文字への参照を用いる、など (訳注: 記号フォントを使った ゥ → ハート のような表示はやめろ、と。))。
この方針の結果として、MathML レンダラーは、第 6 章「文字、実体とフォント」に挙げられた MathML 文字は、指定されたフォントで利用できない場合でも、適切にレンダリングするよう心がけるべきです。
そうした描画ができないはずはありません
- 最新のレポートによれば、どの文字も、第 6 章「文字、実体とフォント」中の同じ文字に割り当てられた実体名を用いれば XML 風の実体参照 として表現可能、とされているからです。
シンボル css-fontfamily は、CSS の font-family プロパティの legal な値を参照します。
CSS の font-family は、カンマで区切られた代替フォント名ないし一般フォントタイプの優先順位付きリストで、CSS [CSS2] で詳細に記述されています。
MathML レンダラーは、たとえ CSS をサポートしていなくても、レンダリング環境において現実的であればフォント指定に CSS 構文が利用できることが期待されます
(第2.4.4.3節「CSS-互換属性」中のCSS-互換属性についての項目も参照してください)。
mathcolor 属性 (および廃止された color 属性) は、トークンの本体の描画に使われる色を制御します。
さらに、mstyle や MathML 式のレンダリング環境から継承する場合は、他のすべての MathML 要素の描画色を制御します。これには、各種の線や、frac, mtable, msqrt によって指定される記号のたぐいを含みます。
mathcolor, color, mathbackground, background の値は、'#'の後に空白を挟まずに 1 桁ないし 2 桁の 16 進の値で赤、緑、青の色素をそれぞれ指定することで、任意の色を表現することができます ( background に対しては `transparent'というキーワードを用いることができます)。16 進の値は、大文字・小文字を区別しません。
それぞれの色素の値は、1 桁なら 0 (色素が存在しない) から F (色素が100%含まれる) まで、2 桁なら 00 (色素が存在しない) から FF (色素が100%含まれる) まで指定することができます。なお、1 桁の x という値は 2 桁の xx という値 (x0 ではありません) と等価です。% x0 という表記の方がより厳密ですが、ブラウザーによってはレンダリングが崩れることがあります。
これらの属性は、後に説明する html-color-name によって指定することもできます。
上で説明した色の構文は、CSS の color および background-color プロパティの構文のサブセットです。
つまり、background-color 構文もまた CSS の background プロパティの構文の完全なサブセットです。background プロパティを用いれば、たとえば背景画像をタイル状に並べるといった指定もできます。一般的な属性名としての background は、MathML では将来的に属性のスコープの拡張を可能にするために用いられています。
それぞれの属性における色の値は、html-color-name で指定することもできます。これは、[HTML4] で定義されている、色名のキーワード (aqua,
black,
blue,
fuchsia,
gray,
green,
lime,
maroon,
navy,
olive,
purple,
red,
silver,
teal,
white,
yellow) のいずれかです。
色名キーワードは、多くのMathML属性値と異なり、CSSおよびHTMLの互換性のために、大文字小文字を区別しないことに注意してください。
The suggested MathML visual rendering rules do not define the
precise extent of the region whose background is affected by using the
(訳注: この部分は原文の誤植のようで、のちに出てくるPrecise background region not specifiedが混入してしまったようです)
background attribute on mstyle,
except that, when mstyle's content does not have
negative dimensions and its drawing region is not overlapped by other
drawing due to surrounding negative spacing, this region should lie
behind all the drawing done to render the content of the
mstyle, but should not lie behind any of the
drawing done to render surrounding expressions. The effect of overlap
of drawing regions caused by negative spacing on the extent of the
region affected by the background attribute is not
defined by these rules.
mi)mi 要素は、識別子(identifier)として描画されるシンボル名や任意のテキストを表現するためのものです。識別子には、変数、関数名、およびシンボル定数を含みます。
必ずしもすべての「数学識別子」(mathematical identifiers) が mi によって表現されるわけではありません - たとえば、下付文字やプライムを伴う変数は、それぞれ msub や msup によって表現されます。
逆に、級数の合計における省略記号のような、「ターム」としての意味を持つ任意のテキストは、mi で表現することができます。この例は 第3.2.6.4節「Mixing text and mathematics」 に挙げられています。
ここで強調しておきたいのは、miは、プレゼンテーション要素であり、従って、その本体が識別子としてレンダリングされるという意味のみをもつ、ということです。
多くの場合、mi 要素の本体は、実際に変数や関数名といった数学識別子を表現します。
しかし、次の段落で説明されるように、識別子であるかのようにレンダリングされる表記と、実際に数学識別子を表現するべき表記の対応は完全ではありません。
その意味が識別子として保証されている要素については、第4章「コンテンツ・マークアップ」 中の ci の説明を参照してください。
mi 要素は、第3.2.2節「トークン要素に共通な数学用スタイル属性」 で挙げられる属性をもつことができますが、
デフォルトの属性値が異なるものがあります:
| 名前 | 値 | デフォルト |
|---|---|---|
| mathvariant | normal | bold | italic | bold-italic | double-struck | bold-fraktur | script | bold-script | fraktur | sans-serif | bold-sans-serif | sans-serif-italic | sans-serif-bold-italic | monospace | (本体に依存; 下で説明します) |
| fontstyle (廃止属性) | normal | italic | (本体に依存; 下で説明します) |
典型的なグラフィカルレンダラーは、mi 要素を描画する際、その周囲に余分な空白をもたないように(周辺要素との間の空白を除く)、要素の本体として含まれる文字を描画するでしょう。
mathvariant および fontstyle のデフォルト値は、要素の本体が一文字でなければ、通常 normal (non-slanted) になりますが、一文字の場合には italic になります。
この規則は mi 要素のみの mathvariant および fontstyle 属性のものである、ということに注意してください;
その他の要素に対する mathvariant および fontstyle 属性のデフォルト値は、(常に) normal です。
数学用英数字記号の文字 (第6.2.3節「数学用英数字記号の文字」 および 第3.2.1.1節「英数字記号の文字」 をご覧下さい) の対応文字を決定する目的のために、上で述べた特殊なデフォルト値に対する挙動を含め、mathvariant 属性の値が最初に解決されることに注意してください。
<mi> x </mi> <mi> D </mi> <mi> sin </mi> <mi mathvariant='script'> L </mi> <mi></mi>
本体を含まない mi 要素もありえます;
たとえば、<mi></mi> という表記は、
(従来の数学構文に従えば) 必要とされる「ターム」をまだ含んでいない MathML 式において、タームの位置を表すために「式エディター」が用いることがあります。
識別子には、「sin」のような関数名が含まれます。
「sin x」のような式は、次のように ⁡ 演算子 (省略名 ⁡ もあります) を用いて書かれるべきです;
第3.2.5節「演算子、囲い文字、区切り文字、アクセント (mo)」 の不可視の演算子についての議論も参照してください。
<mrow> <mi> sin </mi> <mo> ⁡ </mo> <mi> x </mi> </mrow>
「ターム」として扱われるべきその他のテキストは、mi 要素を用いて表現することができます。たとえば:
<mrow> <mn> 1 </mn> <mo> + </mo> <mi> ... </mi> <mo> + </mo> <mi> n </mi> </mrow>
このような例外的な状況で mi が用いられる場合には、
明示的に fontstyle 属性を指定することにより、一部のブラウザーでデフォルトの挙動よりもよい結果が得られることがあります。
シンボル定数名は、mi 要素によって表現されます:
<mi> π </mi> <mi> ⅈ </mi> <mi> ⅇ </mi>
このような定数を表す特別な実体参照を用いることで、MathML のプレゼンテーション要素の解釈が簡単になります。 See Chapter 6 [Characters, Entities and Fonts] for a complete list of character entity references in MathML.
mn)mn 要素は、「数リテラル」や、数リテラルとしてとして描画されるべきその他のデータを表します。一般的に数リテラルは、符号なし整数や実数を表現し、小数点を含みうる数字の連続のことです。
数学における「数」の概念は、非常に微妙で複雑であり、文脈によって異なります。
従って、必ずしも数学上のすべての数が mn を用いて表現されるべきというわけではありません;
数学上の数の異なる表現方法の例を以下に示します。複素数、分数で表される割合、数定数の名前、などを含みます。
数を文字列としてエンコーディングする標準的な方法を用いると、mn 本体の数としての解釈が曖昧になってしまうことがあります。
そのような場合においても、mn はプレゼンテーション要素なので、数リテラルとして描画されることのないその他一般のテキストを mn の本体の中に含むことが望ましい場合がごくまれにあり得ます。
しかし原則的には、mn 要素は、
その本体が実際になんらかの方法で数量を表す場合に用いられるべきです。
何らかの形で数学的な数としての意味が保証されている要素については、
第4章「コンテンツ・マークアップ」 中の cn についての説明を参照してください。
mn 要素は、第3.2.2節「トークン要素に共通な数学用のスタイル属性」 で挙げられた属性を受け付けます。
典型的なグラフィカル・レンダラーは、mn 要素の本体の文字を、その周囲に特別な空白をつけず、そのまま描画するでしょう (ただし、mo のような要素と隣接する場合には空白をおきます)。
mi とは異なり、mn 要素は、(通常) その本体に拘わらず標準で直立な (unslanted) フォントで描画されます。
<mn> 2 </mn> <mn> 0.123 </mn> <mn> 1,000,000 </mn> <mn> 2.1e10 </mn> <mn> 0xFFEF </mn> <mn> MCMLXIX </mn> <mn> twenty one </mn>
mn のみを用いて記述されるべきではない数多くの数学上の数は、mn だけではなく、他のプレゼンテーション要素を用いて表されるべきです; これには、複素数や、分数で表される割合、数定数の名前などが含まれます。このような MathML 表現の例は、以下のようになります:
<mrow>
<mn> 2 </mn>
<mo> + </mo>
<mrow>
<mn> 3 </mn>
<mo> ⁢ </mo>
<mi> ⅈ </mi>
</mrow>
</mrow>
<mfrac> <mn> 1 </mn> <mn> 2 </mn> </mfrac>
<mi> π </mi>
<mi> ⅇ </mi>
mo)mo要素は、演算子もしくは演算子として描画されるべきその他のものを表します。
一般的に、数学で用いられる演算子の表記に関する慣習はとても複雑で、ゆえに MathML では mo 要素のレンダリングの挙動について、やや洗練されたメカニズムを採用しています。
その結果、MathML では従来は数学的な演算子として扱われなかった多くの表記を「演算子として描画される」べきものに含めるようになりました。
これらには、挿入辞・接頭辞・接尾辞の形式をを含めた従来の演算子以外に、大括弧・丸括弧・絶対値記号のような囲い文字、カンマやセミコロンのような区切り文字、そして記号の上部に付けるバーやチルダなどのような数学的なアクセントが含まれます。
用語「演算子」は、この章では演算子として描画されるべき記号ないし表記のことを意味します。従って演算子は、mo によって表されます。つまり、特に指定がなく文脈からも明らかではない場合には、用語「演算子」に既存の演算子、囲い文字、区切り文字、アクセントを含むということです。
このような記号は、基本的に同じレンダリング属性・レンダリング規則に属しているため、MathML ではすべて mo 要素で表されます; レンダリングにおいて記号の種類による些細な区別があれば、ブール (boolean) 属性である fence、separator、accent を用いてその区別を行います。
mo 要素のもっとも大切な特徴は、そのデフォルト値が次に説明するように「演算子辞書」から場合に応じて決定されるということです。特に、fence、separator、accent のデフォルト値は一般に演算子辞書から選ばれ、従って、それぞれの mo 要素に対して個別に指定する必要がありません。
数学演算子の中には、mo 要素のみではなく、(たとえば)周囲の上付き文字によって修飾された mo 要素によって表されるものもあることに注意してください (このことについては後にさらに記述しています)。一方、mo 要素はプレゼンテーション要素なので、
テキストが一般には演算子として扱われない場合でも一般的なテキストを mo 要素に含むことができます。
たとえば、第3.2.6節「テキスト (mtext)」中の「テキストと数学の混合」の議論をご覧下さい。MathML で特定の数学演算子としての意味を含むことが保証されたコンテンツ要素の定義については第4章「コンテンツ・マークアップ」も参照してください。
mo 要素は、
第3.2.2節「トークン要素に共通な数学スタイル属性」 で挙げられた属性と、ここで挙げる追加的な属性ををとることができます。
多くの属性のデフォルト値は、この節の後で述べるとおり 第3.2.5.7.1節「演算子辞書」 にあります。
与えられた mo 要素が辞書のエントリーとして見つからない場合は、ここで括弧付きで示されるデフォルト値が用いられます。
mo elements accept the attributes listed in
Section 3.2.2 [Mathematics style attributes common to token
elements], and the additional attributes listed here.
Most attributes get their default values from the
Section 3.2.5.7.1 [The operator dictionary], as described later in this
section. When a dictionary entry is not found for a given
mo element, the default value shown here in
parentheses is used.
| 属性名 Name |
値 values |
デフォルト default |
|---|---|---|
| form | prefix | infix | postfix |
mrow の中での演算子の位置による (規則は後述);
mo の本体とともに演算子辞書をインデックス付けするために用いられる
set by position of operator in an mrow (rule given below);
used with mo content to index operator dictionary |
| fence | true | false | 辞書によって決定 (false) set by dictionary (false) |
| separator | true | false | 辞書によって決定 (false) set by dictionary (false) |
| lspace | number h-unit | namedspace | 辞書によって決定 (thickmathspace) set by dictionary (thickmathspace) |
| rspace | number h-unit | namedspace | 辞書によって決定 (thickmathspace) set by dictionary (thickmathspace) |
| stretchy | true | false | 辞書によって決定 (false) set by dictionary (false) |
| symmetric | true | false | 辞書によって決定 (true) set by dictionary (true) |
| maxsize | number [ v-unit | h-unit ] | namedspace | infinity | 辞書によって決定 (infinity) set by dictionary (infinity) |
| minsize | number [ v-unit | h-unit ] | namedspace | 辞書によって決定 (1) set by dictionary (1) |
| largeop | true | false | 辞書によって決定 (false) set by dictionary (false) |
| movablelimits | true | false | 辞書によって決定 (false) set by dictionary (false) |
| accent | true | false | 辞書によって決定 (false) set by dictionary (false) |
h-unit represents a unit of horizontal
length, and v-unit represents a unit of vertical
length (see
Section 2.4.4.2 [Attributes with units]).
namedspace is one of
veryverythinmathspace,
verythinmathspace,
thinmathspace,
mediummathspace,
thickmathspace,
verythickmathspace, or
veryverythickmathspace.
These values can be set by using the mstyle element
as is further discussed in Section 3.3.4 [Style Change (mstyle)].
If no unit is given with maxsize or minsize, the number is a multiplier of the normal size
of the operator in the direction (or directions) in which it stretches.
These attributes are further explained below.
Typical graphical renderers show all mo
elements as the characters of their content, with additional spacing
around the element determined from the attributes listed
above. Detailed rules for determining operator spacing in visual
renderings are described in a subsection below. As always, MathML does
not require a specific rendering, and these rules are provided as
suggestions for the convenience of implementors.
Renderers without access to complete fonts for the MathML character
set may choose not to render an mo element as
precisely the characters in its content in some cases. For example,
<mo> ≤ </mo> might be rendered as
<= to a terminal. However, as a general rule,
renderers should attempt to render the content of an
mo element as literally as possible.
That is,
<mo> ≤ </mo> and
<mo> <= </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> + </mo> <mo> < </mo> <mo> ≤ </mo> <mo> <= </mo> <mo> ++ </mo> <mo> ∑ </mo> <mo> .NOT. </mo> <mo> and </mo> <mo> ⁢ </mo> <mo mathvariant='bold'> + </mo>
Note that the mo elements in these examples
don't need explicit fence or separator attributes, since these can be found using the
operator dictionary as described below. Some of these examples could also
be encoded using the mfenced element described in
Section 3.3.8 [Expression Inside Pair of Fences
(mfenced)].
(a+b)
<mrow>
<mo> ( </mo>
<mrow>
<mi> a </mi>
<mo> + </mo>
<mi> b </mi>
</mrow>
<mo> ) </mo>
</mrow>
[0,1)
<mrow>
<mo> [ </mo>
<mrow>
<mn> 0 </mn>
<mo> , </mo>
<mn> 1 </mn>
</mrow>
<mo> ) </mo>
</mrow>
f(x,y)
<mrow>
<mi> f </mi>
<mo> ⁡ </mo>
<mrow>
<mo> ( </mo>
<mrow>
<mi> x </mi>
<mo> , </mo>
<mi> y </mi>
</mrow>
<mo> ) </mo>
</mrow>
</mrow>
Certain operators that are `invisible' in traditional
mathematical notation should be represented using specific entity
references within mo elements, rather than simply
by nothing. The entity references used for these `invisible
operators' are:
| Full name | Short name | Examples of use |
|---|---|---|
⁢ |
⁢ |
xy |
⁡ |
⁡ |
f(x) sin x |
⁣ |
⁣ |
m12 |
The MathML representations of the examples in the above table are:
<mrow>
<mi> x </mi>
<mo> ⁢ </mo>
<mi> y </mi>
</mrow>
<mrow>
<mi> f </mi>
<mo> ⁡ </mo>
<mrow>
<mo> ( </mo>
<mi> x </mi>
<mo> ) </mo>
</mrow>
</mrow>
<mrow>
<mi> sin </mi>
<mo> ⁡ </mo>
<mi> x </mi>
</mrow>
<msub>
<mi> m </mi>
<mrow>
<mn> 1 </mn>
<mo> ⁣ </mo>
<mn> 2 </mn>
</mrow>
</msub>
The reasons for using specific mo elements for
invisible operators include:
mspace or mtext
elements;
For example, an audio renderer might render f(x)
(represented as in the above examples) by speaking `f of x', but use
the word `times' in its rendering of xy.
Although its rendering must still be different depending on the structure
of neighboring elements (sometimes leaving out `of' or
`times' entirely), its task is made much easier by the use of
a different mo element for each invisible
operator.
MathML also includes ⅆ for use
in an mo element representing the differential
operator symbol usually denoted by `d'. The reasons for
explicitly using this special entity are similar to those for using
the special entities for invisible operators described in the
preceding section.
mo elementsTypical visual rendering behaviors for mo
elements are more complex than for the other MathML token elements, so
the rules for rendering them are described in this separate
subsection.
Note that, like all rendering rules in MathML, these rules are suggestions rather than requirements. Furthermore, no attempt is made to specify the rendering completely; rather, enough information is given to make the intended effect of the various rendering attributes as clear as possible.
Many mathematical symbols, such as an integral sign, a plus sign,
or a parenthesis, have a well-established, predictable, traditional
notational usage. Typically, this usage amounts to certain default
attribute values for mo elements with specific
contents and a specific form attribute. Since these
defaults vary from symbol to symbol, MathML anticipates that renderers
will have an `operator dictionary' of default attributes for
mo elements (see Appendix F [Operator Dictionary]) indexed by each
mo element's content and form
attribute. If an mo element is not listed in the
dictionary, the default values shown in parentheses in the table of
attributes for mo should be used, since these
values are typically acceptable for a generic operator.
Some operators are `overloaded', in the sense that they can occur
in more than one form (prefix, infix, or postfix), with possibly
different rendering properties for each form. For example, `+' can be
either a prefix or an infix operator. Typically, a visual renderer
would add space around both sides of an infix operator, while only on
the left of a prefix operator. The form attribute allows
specification of which form to use, in case more than one form is
possible according to the operator dictionary and the default value
described below is not suitable.
form attributeThe form attribute does not usually have to be
specified explicitly, since there are effective heuristic rules for
inferring the value of the form attribute from the
context. If it is not specified, and there is more than one possible
form in the dictionary for an mo element with
given content, the renderer should choose which form to use as follows
(but see the exception for embellished operators, described later):
mrow of length (i.e. number of arguments) greater than
one (ignoring all space-like arguments (see Section 3.2.7 [Space (mspace)]) in the
determination of both the length and the first argument), the prefix form
is used;
mrow of
length greater than one (ignoring all space-like arguments), the postfix
form is used;
mrow, the infix form is used.
Note that these rules make reference to the
mrow in which the mo
element lies. In some situations, this mrow
might be an inferred mrow implicitly present
around the arguments of an element such as
msqrt or mtd.
Opening (left) fences should have form="prefix",
and closing (right) fences should have form="postfix";
separators are usually `infix', but not always,
depending on their surroundings. As with ordinary operators,
these values do not usually need to be specified explicitly.
If the operator does not occur in the dictionary with the specified
form, the renderer should use one of the forms that is available
there, in the order of preference: infix, postfix, prefix; if no forms
are available for the given mo element content, the
renderer should use the defaults given in parentheses in the table of
attributes for mo.
There is one exception to the above rules for choosing an mo element's default form
attribute. An mo element that is
`embellished' by one or more nested subscripts, superscripts,
surrounding text or whitespace, or style changes behaves differently. It is
the embellished operator as a whole (this is defined precisely, below)
whose position in an mrow is examined by the above
rules and whose surrounding spacing is affected by its form, not the mo element at its core; however, the attributes
influencing this surrounding spacing are taken from the mo element at the core (or from that element's
dictionary entry).
For example, the `+4' in
a+4b
should be considered an infix operator as a whole, due to its position
in the middle of an mrow, but its rendering
attributes should be taken from the mo element
representing the `+', or when those are not specified explicitly,
from the operator dictionary entry for <mo form="infix"> +
</mo>.
The precise definition of an `embellished operator' is:
mo element;
msub,
msup,
msubsup,
munder,
mover,
munderover,
mmultiscripts,
mfrac, or
semantics
(Section 4.2.6 [Syntax and Semantics]), whose first argument exists and is an embellished
operator;
mstyle,
mphantom, or
mpadded,
such that an mrow containing the same
arguments would be an embellished operator;
maction element whose selected
sub-expression exists and is an embellished operator; mrow whose arguments consist (in any order)
of one embellished operator and zero or more space-like elements.
Note that this definition permits nested embellishment only when there are no intervening enclosing elements not in the above list.
The above rules for choosing operator forms and defining
embellished operators are chosen so that in all ordinary cases it will
not be necessary for the author to specify a form
attribute.
The following notes are included as a rationale for certain aspects of the above definitions, but should not be important for most users of MathML.
An mfrac is included as an
`embellisher' because of the common notation for a
differential operator:
<mfrac>
<mo> ⅆ </mo>
<mrow>
<mo> ⅆ </mo>
<mi> x </mi>
</mrow>
</mfrac>
Since the definition of embellished operator affects the use of the
attributes related to stretching, it is important that it includes
embellished fences as well as ordinary operators; thus it applies to
any mo element.
Note that an mrow containing a single argument
is an embellished operator if and only if its argument is an embellished
operator. This is because an mrow with a single
argument must be equivalent in all respects to that argument alone (as
discussed in Section 3.3.1 [Horizontally Group Sub-Expressions
(mrow)]). This means that an mo element that is the sole argument of an mrow will determine its default form attribute based on that mrow's position in a surrounding, perhaps inferred, mrow (if there is one), rather than based on its own
position in the mrow in which it is the sole
argument.
Note that the above definition defines every
mo element to be `embellished' - that is,
`embellished operator' can be considered (and implemented in
renderers) as a special class of MathML expressions, of which
mo is a specific case.
The amount of space added around an operator (or embellished operator),
when it occurs in an mrow, can be directly
specified by the lspace and rspace attributes. These values are in ems if no units
are given. By convention, operators that tend to bind tightly to their
arguments have smaller values for spacing than operators that tend to bind
less tightly. This convention should be followed in the operator dictionary
included with a MathML renderer. In TEX, these values can only be one of
three values; typically they are 3/18em, 4/18em, and 5/18em. MathML does
not impose this limit.
Some renderers may choose to use no space around most operators appearing within subscripts or superscripts, as is done in TEX.
Non-graphical renderers should treat spacing attributes, and other rendering attributes described here, in analogous ways for their rendering medium. For example, more space might translate into a longer pause in an audio rendering.
Four attributes govern whether and how an operator (perhaps embellished)
stretches so that it matches the size of other elements: stretchy, symmetric, maxsize, and minsize. If an
operator has the attribute stretchy=true, then it (that is, each character in its content)
obeys the stretching rules listed below, given the constraints imposed by
the fonts and font rendering system. In practice, typical renderers will
only be able to stretch a small set of characters, and quite possibly will
only be able to generate a discrete set of character sizes.
There is no provision in MathML for specifying in which direction
(horizontal or vertical) to stretch a specific character or operator;
rather, when stretchy=true it
should be stretched in each direction for which stretching is possible. It
is up to the renderer to know in which directions it is able to stretch
each character. (Most characters can be stretched in at most one direction
by typical renderers, but some renderers may be able to stretch certain
characters, such as diagonal arrows, in both directions independently.)
The minsize and maxsize
attributes limit the amount of stretching (in either direction). These two
attributes are given as multipliers of the operator's normal size in the
direction or directions of stretching, or as absolute sizes using units.
For example, if a character has maxsize="3", then it
can grow to be no more than three times its normal (unstretched) size.
The symmetric attribute governs whether the
height and
depth above and below the axis of the
character are forced to be equal
(by forcing both height and depth to become the maximum of the two).
An example of a situation where one might set
symmetric=false
arises with parentheses around a matrix not aligned on the axis, which
frequently occurs when multiplying non-square matrices. In this case, one
wants the parentheses to stretch to cover the matrix, whereas stretching
the parentheses symmetrically would cause them to protrude beyond one edge
of the matrix. The symmetric attribute only applies
to characters that stretch vertically (otherwise it is ignored).
If a stretchy mo element is embellished (as defined
earlier in this section), the mo element at its core is
stretched to a size based on the context of the embellished operator
as a whole, i.e. to the same size as if the embellishments were not
present. For example, the parentheses in the following example (which
would typically be set to be stretchy by the operator dictionary) will be
stretched to the same size as each other, and the same size they would
have if they were not underlined and overlined, and furthermore will
cover the same vertical interval:
<mrow>
<munder>
<mo> ( </mo>
<mo> _ </mo>
</munder>
<mfrac>
<mi> a </mi>
<mi> b </mi>
</mfrac>
<mover>
<mo> ) </mo>
<mo> ‾ </mo>
</mover>
</mrow>
Note that this means that the stretching rules given below must
refer to the context of the embellished operator as a whole, not just
to the mo element itself.
This shows one way to set the maximum size of a parenthesis so that
it does not grow, even though its default value is
stretchy=true.
<mrow>
<mo maxsize="1"> ( </mo>
<mfrac>
<mi> a </mi> <mi> b </mi>
</mfrac>
<mo maxsize="1"> ) </mo>
</mrow>
The above should render as
as opposed to the default rendering
.
Note that each parenthesis is sized independently; if only one of
them had maxsize="1", they would render with different
sizes.
mrow element, or is the sole direct sub-expression of an
mtd element in some row of a table, then it should
stretch to cover the height and depth (above and below the axis) of the non-stretchy direct sub-expressions in the
mrow element or table row, unless stretching is
constrained by minsize or maxsize attributes.
symmetric=true,
then the maximum of the height and depth is used to determine the size,
before application of the minsize or maxsize attributes.
mrow element is inferred.
Most common opening and closing fences are defined in the operator
dictionary to stretch by default; and they stretch vertically. Also,
operators such as ∑, ∫,
/, and vertical arrows stretch vertically by default.
In the case of a stretchy operator in a table cell (i.e. within an
mtd element), the above rules assume each cell of
the table row containing the stretchy operator covers exactly one row.
(Equivalently, the value of the rowspan attribute is
assumed to be 1 for all the table cells in the table row, including
the cell containing the operator.) When this is not the case, the
operator should only be stretched vertically to cover those table
cells that are entirely within the set of table rows that the
operator's cell covers. Table cells that extend into rows not covered
by the stretchy operator's table cell should be ignored. See
Section 3.5.4.2 [Attributes] for details about the rowspan attribute.
munder,
mover, or munderover element,
or if it is the sole direct sub-expression of an mtd element in some
column of a table (see mtable), then it, or the mo element at its core, should stretch to cover
the width of the other direct sub-expressions in the given element (or
in the same table column), given the constraints mentioned above.
munder, mover, or
munderover element, or if it is the sole direct
sub-expression of an mtd element in some column of a
table, then it should stretch to cover the width of the other direct
sub-expressions in the given element (or in the same table column),
given the constraints mentioned above.
By default, most horizontal arrows and some accents stretch horizontally.
In the case of a stretchy operator in a table cell (i.e. within an
mtd element), the above rules assume each cell of
the table column containing the stretchy operator covers exactly one
column. (Equivalently, the value of the columnspan
attribute is assumed to be 1 for all the table cells in the table row,
including the cell containing the operator.) When this is not the
case, the operator should only be stretched horizontally to cover
those table cells that are entirely within the set of table columns
that the operator's cell covers. Table cells that extend into columns
not covered by the stretchy operator's table cell should be
ignored. See Section 3.5.4.2 [Attributes] for details about the rowspan attribute.
The rules for horizontal stretching include mtd
elements to allow arrows to stretch for use in commutative diagrams
laid out using mtable. The rules for the horizontal
stretchiness include scripts to make examples such as the following
work:
<mrow>
<mi> x </mi>
<munder>
<mo> → </mo>
<mtext> maps to </mtext>
</munder>
<mi> y </mi>
</mrow>
This displays as
.
If a stretchy operator is not required to stretch (i.e. if it is not in one of the locations mentioned above, or if there are no other expressions whose size it should stretch to match), then it has the standard (unstretched) size determined by the font and current fontsize.
If a stretchy operator is required to stretch, but all other expressions
in the containing element (as described above) are also stretchy,
all elements that can stretch should grow to the maximum of the normal
unstretched sizes of all elements in the containing object, if they can
grow that large. If the value of minsize or maxsize prevents this then that (min or max) size is
used.
For example, in an mrow containing nothing but
vertically stretchy operators, each of the operators should stretch to
the maximum of all of their normal unstretched sizes, provided no
other attributes are set that override this behavior. Of course,
limitations in fonts or font rendering may result in the final,
stretched sizes being only approximately the same.
mo
The largeop attribute specifies whether the
operator should be drawn larger than normal if displaystyle=true in the current
rendering environment. This roughly corresponds to TEX's
\displaystyle style setting. MathML uses two attributes, displaystyle and scriptlevel, to
control orthogonal presentation features that TEX encodes into one
`style' attribute with values \displaystyle,
\textstyle, \scriptstyle, and
\scriptscriptstyle. These attributes are discussed further in
Section 3.3.4 [Style Change (mstyle)] describing the mstyle element.
Note that these attributes can be specified directly on an mstyle element's start tag, but not on most other
elements. Examples of large operators include ∫
and ∏.
The movablelimits attribute specifies whether
underscripts and overscripts attached to this mo
element should be drawn as subscripts and superscripts when displaystyle=false. movablelimits=false means that
underscripts and overscripts should never be drawn as subscripts and
superscripts. In general, displaystyle is true for displayed mathematics and false for inline mathematics. Also, displaystyle is false by default
within tables, scripts and fractions, and a few other exceptional
situations detailed in Section 3.3.4 [Style Change (mstyle)]. Thus, operators with
movablelimits=true will
display with limits (i.e. underscripts and overscripts) in displayed
mathematics, and with subscripts and superscripts in inline mathematics,
tables, scripts and so on. Examples of operators that typically have movablelimits=true are sum, prod, and lim.
The accent attribute determines whether this
operator should be treated by default as an accent (diacritical mark) when
used as an underscript or overscript; see munder,
mover, and munderover
(Section 3.4.4 [Underscript (munder)], Section 3.4.5 [Overscript (mover)] and Section 3.4.6 [Underscript-overscript Pair
(munderover)]).
The separator attribute may affect automatic
linebreaking in renderers that position ordinary infix operators at
the beginnings of broken lines rather than at the ends (that is, which
avoid linebreaking just after such operators), since linebreaking
should be avoided just before separators, but is acceptable just after
them.
The fence attribute has no effect in the suggested
visual rendering rules given here; it is not needed for properly
rendering traditional notation using these rules. It is provided so
that specific MathML renderers, especially non-visual renderers, have
the option of using this information.
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.
Note that some text with a clearly defined notational role might be
more appropriately marked up using mi or
mo; this is discussed further below.
An mtext element can be used to contain
`renderable whitespace', i.e. invisible characters that are
intended to alter the positioning of surrounding elements. In non-graphical
media, such characters are intended to have an analogous effect, such as
introducing positive or negative time delays or affecting rhythm in an
audio renderer. This is not related to any whitespace in the source MathML
consisting of blanks, newlines, tabs, or carriage returns; whitespace
present directly in the source is trimmed and collapsed, as described in
Section 2.4.6 [Collapsing Whitespace in Input]. Whitespace that is intended to be rendered
as part of an element's content must be represented by entity references
or mspace elements
(unless it consists only of single blanks between non-whitespace
characters).
Renderable whitespace can have a positive or negative width, as in   and ​,
or zero width, as in ​. The complete
list of such characters is given in Chapter 6 [Characters, Entities and Fonts]. Note that there
is no formal distinction in MathML between renderable whitespace characters
and any other class of characters, in mtext or in
any other element.
Renderable whitespace can also include characters that affect alignment or linebreaking. Some of these characters are:
| Entity name | Purpose (rough description) |
|---|---|
| 
 | start a new line and do not indent |
| &IndentingNewLine; | start a new line and do indent |
| ⁠ | do not allow a linebreak here |
| &GoodBreak; | if a linebreak is needed on the line, here is a good spot |
| &BadBreak; | if a linebreak is needed on the line, try to avoid breaking here |
For the complete list of MathML entities, consult Chapter 6 [Characters, Entities and Fonts].
mtext elements accept the attributes listed in
Section 3.2.2 [Mathematics style attributes common to token
elements].
See also the warnings about the legal grouping of `space-like
elements' in Section 3.2.7 [Space (mspace)], and about the use of
such elements for `tweaking' or conveying meaning in Section 3.3.6 [Adjust Space Around Content
(mpadded)].
<mtext> Theorem 1: </mtext> <mtext>   </mtext> <mtext>      </mtext> <mtext> /* a comment */ </mtext>
In some cases, text embedded in mathematics could be more appropriately
represented using mo or mi elements.
For example, the expression `there exists
such that f(x) <1' is equivalent to
and could be represented as:
<mrow>
<mo> there exists </mo>
<mrow>
<mrow>
<mi> δ </mi>
<mo> > </mo>
<mn> 0 </mn>
</mrow>
<mo> such that </mo>
<mrow>
<mrow>
<mi> f </mi>
<mo> ⁡ </mo>
<mrow>
<mo> ( </mo>
<mi> x </mi>
<mo> ) </mo>
</mrow>
</mrow>
<mo> < </mo>
<mn> 1 </mn>
</mrow>
</mrow>
</mrow>
An example involving an mi element is:
x+x2+···+xn.
In this example, ellipsis should be represented using an mi element, since it takes the place of a term in the
sum; (see Section 3.2.3 [Identifier (mi)]).
On the other hand, expository text within MathML is best
represented with an mtext element. An example
of this is:
Theorem 1: if x > 1, then x2 > x.
However, when MathML is embedded in HTML, or another document markup language, the example is probably best rendered with only the two inequalities represented as MathML at all, letting the text be part of the surrounding HTML.
Another factor to consider in deciding how to mark up text is the
effect on rendering. Text enclosed in an mo
element is unlikely to be found in a renderer's operator dictionary,
so it will be rendered with the format and spacing appropriate for an
`unrecognized operator', which may or may not be better than the
format and spacing for `text' obtained by using an
mtext element. An ellipsis entity in an
mi element is apt to be spaced more appropriately
for taking the place of a term within a series than if it appeared in
an mtext element.
mspace)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.
In addition to the attributes listed below,
mspace permits
id,
xref, class and
style attributes,
as described in Section 2.4.5 [Attributes Shared by all MathML Elements].
| Name | values | default |
|---|---|---|
| width | number h-unit | namedspace | 0em |
| height | number v-unit | 0ex |
| depth | number v-unit | 0ex |
| linebreak | auto | newline | indentingnewline | nobreak | goodbreak | badbreak | auto |
h-unit and v-unit
represent units of horizontal or vertical length, respectively (see
Section 2.4.4.2 [Attributes with units]).
The linebreak attribute is used to give a
linebreaking hint to a visual renderer. The default value is auto, which indicates that a renderer should use
whatever default linebreaking algorithm it would normally use. The
meaning of the other possible values for the linebreak attribute are described above in the
discussion on renderable whitespace in the mtext element. See Section 3.2.6 [Text (mtext)]
for details.
In the case when both dimensional attributes and a linebreaking attribute are set, the linebreaking attribute is ignored.
Note the warning about the legal grouping of `space-like elements'
given below, and the warning about the use of such elements for
`tweaking' or conveying meaning in Section 3.3.6 [Adjust Space Around Content
(mpadded)]. See also the other
elements that can render as whitespace, namely
mtext, mphantom, and
maligngroup.
A number of MathML presentation elements are `space-like' in the
sense that they typically render as whitespace, and do not affect the
mathematical meaning of the expressions in which they appear. As a
consequence, these elements often function in somewhat exceptional
ways in other MathML expressions. For example, space-like elements are
handled specially in the suggested rendering rules for
mo given in Section 3.2.5 [Operator, Fence, Separator or Accent
(mo)].
The following MathML elements are defined to be `space-like':
mtext, mspace,
maligngroup, or malignmark
element; mstyle, mphantom, or
mpadded element, all of whose direct sub-expressions
are space-like; maction element whose selected
sub-expression exists and is space-like; mrow all of whose direct
sub-expressions are space-like.
Note that an mphantom is not
automatically defined to be space-like, unless its content is
space-like. This is because operator spacing is affected by whether
adjacent elements are space-like. Since the
mphantom element is primarily intended as an aid
in aligning expressions, operators adjacent to an
mphantom should behave as if they were adjacent
to the contents of the mphantom,
rather than to an equivalently sized area of whitespace.
Authors who insert space-like elements or
mphantom elements into an existing MathML
expression should note that such elements are counted as
arguments, in elements that require a specific number of arguments,
or that interpret different argument positions differently.
Therefore, space-like elements inserted into such a MathML element
should be grouped with a neighboring argument of that element by
introducing an mrow for that purpose. For example,
to allow for vertical alignment on the right edge of the base of a
superscript, the expression
<msup> <mi> x </mi> <malignmark edge="right"/> <mn> 2 </mn> </msup>
is illegal, because msup must have exactly 2 arguments;
the correct expression would be:
<msup>
<mrow>
<mi> x </mi>
<malignmark edge="right"/>
</mrow>
<mn> 2 </mn>
</msup>
See also the warning about `tweaking' in
Section 3.3.6 [Adjust Space Around Content
(mpadded)].
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. As explained in Section 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.
Note that the string literals encoded by ms
are `Unicode strings' rather than `ASCII
strings'. In practice, non-ASCII characters will typically be
represented by entity references. For example,
<ms>&</ms> represents a
string literal containing a single character, &, and
<ms>&amp;</ms> represents a
string literal containing 5 characters, the first one of which is
&.
Like all token elements, ms does trim and
collapse whitespace in its content according to the rules of
Section 2.4.6 [Collapsing Whitespace in Input], so whitespace intended to remain in
the content should be encoded as described in that section.
ms elements accept the attributes listed in
Section 3.2.2 [Mathematics style attributes common to token
elements], and additionally:
| Name | values | default |
|---|---|---|
| lquote | string | " |
| rquote | string | " |
In visual renderers, the content of an ms
element is typically rendered with no extra spacing added around the
string, and a quote character at the beginning and the end of the
string. By default, the left and right quote characters are both the
standard double quote character ". However,
these characters can be changed with the lquote and
rquote attributes respectively.
The content of ms elements should be rendered
with visible `escaping' of certain characters in the content,
including at least `double quote' itself, and preferably whitespace
other than individual 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
\"".
mglyph)Unicode defines a large number of characters used in mathematics, and in most cases, glyphs representing these characters are widely available in a variety of fonts. Although these characters should meet almost all users needs, MathML recognizes that mathematics is not static and that new characters are added when convenient. Characters that become well accepted will likely be eventually incorporated by the Unicode Consortium or other standards bodies, but that is often a lengthy process. In the meantime, a mechanism is necessary for accessing glyphs from non-standard fonts representing these characters.
The mglyph element is the means by which
users can directly access glyphs for characters that are not defined
by Unicode, or not known to the renderer. Similarly, the mglyph element can also be used to select glyph
variants for existing Unicode characters, as might be desirable when a
glyph variant has begun to differentiate itself as a new character by
taking on a distinguished mathematical meaning.
The mglyph element names a specific
character glyph, and is valid inside any MathML leaf content listed in
Section 3.1.6 [Summary of Presentation Elements] (mi, etc.) or
Section 4.2.2 [Containers] (ci, etc.)
unless otherwise restricted by an attribute (e.g. base=2 to <cn>). In order
for a visually-oriented renderer to render the character, the renderer
must be told what font to use and what index within that font to
use.
mglyph elements accept the attributes listed in
Section 3.2.2 [Mathematics style attributes common to token
elements], and the additional attributes listed here.
| Name | values | default |
|---|---|---|
| alt | string | required |
| fontfamily | string | css-fontfamily | required |
| index | integer | required |
The alt attribute provides an alternate name
for the glyph. If the specified font can't be found, the renderer may
use this name in a warning message or some unknown glyph notation. The
name might also be used by an audio renderer or symbol processing
system and should be chosen to be descriptive. The fontfamily and index
uniquely identify the mglyph; two mglyphs with the same values for fontfamily and index should
be considered identical by applications that must determine whether
two characters/glyphs are identical. The alt
attribute should not be part of the identity test.
The fontfamily and index attributes name a font and position within
that font. All font properties apart from fontfamily are inherited. Variants of the font
(e.g., bold) that may be inherited may be ignored if the variant of
the font is not present.
Authors should be aware that rendering requires the fonts
referenced by mglyph, which the MathML
renderer may not have access to or may be not be supported by the
system on which the renderer runs. For these reasons, authors are
encouraged to use mglyph only when
absolutely necessary, and not for stylistic purposes.
The following example illustrates how a researcher might use the mglyph construct with an experimental font to work
with braid group notation.
<mrow> <mi><mglyph fontfamily="my-braid-font" index="2" alt="23braid"/></mi> <mo>+</mo> <mi><mglyph fontfamily="my-braid-font" index="5" alt="132braid"/></mi> <mo>=</mo> <mi><mglyph fontfamily="my-braid-font" index="3" alt="13braid"/></mi> </mrow>
This might render as:
Besides tokens there are several families of MathML presentation elements. One family of elements deals with various `scripting' notations, such as subscript and superscript. Another family is concerned with matrices and tables. The remainder of the elements, discussed in this section, describe other basic notations such as fractions and radicals, or deal with general functions such as setting style properties and error handling.
mrow)An mrow element is used to group together any
number of sub-expressions, usually consisting of one or more mo elements acting as `operators' on one
or more other expressions that are their `operands'.
Several elements automatically treat their arguments as if they were
contained in an mrow element. See the discussion of
inferred mrows in Section 3.1.3 [Required Arguments]. See also mfenced (Section 3.3.8 [Expression Inside Pair of Fences
(mfenced)]), which can effectively form an mrow containing its arguments separated by commas.
This element only permits id,
xref, class and
style attributes,
as described in Section 2.4.5 [Attributes Shared by all MathML Elements].
mrow elements are typically rendered visually
as a horizontal row of their arguments, left to right in the order in
which the arguments occur, or audibly as a sequence of renderings of
the arguments. The description in Section 3.2.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 is designed to allow renderers to automatically linebreak expressions (that is, to break excessively long expressions into several lines), without requiring authors to specify explicitly how this should be done. This is because linebreaking positions can't be chosen well without knowing the width of the display device and the current font size, which for many uses of MathML will not be known except by the renderer at the time of each rendering.
Determining good positions for linebreaks is complex, and rules for
this are not described here; whether and how it is done is up to each
MathML renderer. Typically, linebreaking will involve selection of
`good' points for insertion of linebreaks between successive
arguments of mrow elements.
Although MathML does not require linebreaking or specify a
particular linebreaking algorithm, it has several features designed to
allow such algorithms to produce good results. These include the use
of special entities for certain operators, including invisible
operators (see Section 3.2.5 [Operator, Fence, Separator or Accent
(mo)]), or for providing hints related to
linebreaking when necessary (see Section 3.2.6 [Text (mtext)]), and the ability to
use nested mrows to describe sub-expression
structure (see below).
mrow of one argumentMathML renderers are required to treat an mrow
element containing exactly one argument as equivalent in all ways to
the single argument occurring alone, provided there are no attributes
on the mrow element's start tag. If there are
attributes on the mrow element's start tag, no
requirement of equivalence is imposed. This equivalence condition is
intended to simplify the implementation of MathML-generating software
such as template-based authoring tools. It directly affects the
definitions of embellished operator and space-like element and the
rules for determining the default value of the form
attribute of an mo element;
see Section 3.2.5 [Operator, Fence, Separator or Accent
(mo)] and Section 3.2.7 [Space (mspace)]. See also the discussion of equivalence of MathML
expressions in Chapter 7 [The MathML Interface].
mrow
Sub-expressions should be grouped by the document author in the same way
as they are grouped in the mathematical interpretation of the expression;
that is, according to the underlying `syntax tree' of the
expression. Specifically, operators and their mathematical arguments should
occur in a single mrow; more than one operator
should occur directly in one mrow only when they
can be considered (in a syntactic sense) to act together on the interleaved
arguments, e.g. for a single parenthesized term and its parentheses, for
chains of relational operators, or for sequences of terms separated by
+ and -. A precise rule is given below.
Proper grouping has several purposes: it improves display by possibly affecting spacing; it allows for more intelligent linebreaking and indentation; and it simplifies possible semantic interpretation of presentation elements by computer algebra systems, and audio renderers.
Although improper grouping will sometimes result in suboptimal
renderings, and will often make interpretation other than pure visual
rendering difficult or impossible, any grouping of expressions using
mrow is allowed in MathML syntax; that is,
renderers should not assume the rules for proper grouping will be
followed.
A precise rule for when and how to nest sub-expressions using
mrow is especially desirable when generating
MathML automatically by conversion from other formats for displayed
mathematics, such as TEX, which don't always specify how sub-expressions
nest. When a precise rule for grouping is desired, the following rule
should be used:
Two adjacent operators (i.e. mo elements,
possibly embellished), possibly separated by operands (i.e. anything
other than operators), should occur in the same
mrow only when the left operator has an infix or
prefix form (perhaps inferred), the right operator has an infix or
postfix form, and the operators are listed in the same group of
entries in the operator dictionary provided in Appendix F [Operator Dictionary].
In all other cases, nested mrows should be used.
When forming a nested mrow (during generation
of MathML) that includes just one of two successive operators with
the forms mentioned above (which mean that either operator could in
principle act on the intervening operand or operands), it is necessary
to decide which operator acts on those operands directly (or would do
so, if they were present). Ideally, this should be determined from the
original expression; for example, in conversion from an
operator-precedence-based format, it would be the operator with the
higher precedence. If this cannot be determined directly from the
original expression, the operator that occurs later in the suggested
operator dictionary (Appendix F [Operator Dictionary]) can be assumed to have
a higher precedence for this purpose.
Note that the above rule has no effect on whether any MathML expression is valid, only on the recommended way of generating MathML from other formats for displayed mathematics or directly from written notation.
(Some of the terminology used in stating the above rule in defined
in Section 3.2.5 [Operator, Fence, Separator or Accent
(mo)].)
As an example, 2x+y-z should be written as:
<mrow>
<mrow>
<mn> 2 </mn>
<mo> ⁢ </mo>
<mi> x </mi>
</mrow>
<mo> + </mo>
<mi> y </mi>
<mo> - </mo>
<mi> z </mi>
</mrow>
The proper encoding of (x, y) furnishes a less obvious
example of nesting mrows:
<mrow>
<mo> ( </mo>
<mrow>
<mi> x </mi>
<mo> , </mo>
<mi> y </mi>
</mrow>
<mo> ) </mo>
</mrow>
In this case, a nested mrow is required inside
the parentheses, since parentheses and commas, thought of as fence and
separator `operators', do not act together on their arguments.
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> numerator denominator </mfrac>
mfrac
In addition to the attributes listed below, this element permits
id,
xref, class and
style attributes,
as described in Section 2.4.5 [Attributes Shared by all MathML Elements].
| Name | values | default |
|---|---|---|
| linethickness | number [ v-unit ] | thin | medium | thick | 1 (rule thickness) |
| numalign | left | center | right | center |
| denomalign | left | center | right | center |
| bevelled | true | false | false |
The linethickness attribute indicates the thickness of
the horizontal `fraction bar', or `rule', typically used to render
fractions. A fraction with linethickness="0" renders
without the bar, and might be used within binomial coefficients. A
linethickness greater than one might be used with nested
fractions. These cases are shown below:
In general, the value of linethickness can be a
number, as a multiplier of the default thickness of the fraction bar
(the default thickness is not specified by MathML), or a number with a
unit of vertical length (see Section 2.4.4.2 [Attributes with units]), or one of the keywords
medium (same as 1), thin (thinner than 1,
otherwise up to the renderer), or thick (thicker than 1,
otherwise up to the renderer).
The numalign and
denomalign attributes control the horizontal
alignment of the numerator and denominator respectively. Typically,
numerators and denominators are centered, but a very long numerator or
denominator might be displayed on several lines and a left alignment
might be more appropriate for displaying them.
The bevelled attribute determines whether the
fraction is displayed with the numerator above the denominator
separated by a horizontal line or
whether a diagonal line is used to separate a slightly raised
numerator from a slightly lowered denominator. The latter form
corresponds to the attribute value being true
and provides for a more compact form for simple numerator and
denominators. An exa
