The following table gives the suggested dictionary of rendering
properties for operators, fences, separators, and accents in MathML, all of
which are represented by mo elements. For brevity,
all such elements will be called simply "operators" in this
Appendix.

F.1 Format of operator dictionary entries

The operators are divided into groups, which are separated by blank
lines in the listing below. The grouping, and the order of the groups, is
significant for the proper grouping of sub-expressions using <mrow> (Section 3.3.1 Horizontally Group Sub-Expressions
(mrow)); the rule described
there is especially relevant to the automatic generation of MathML by
conversion from other formats for displayed mathematics, such as TEX,
which do not always specify how sub-expressions nest.

The format of the table entries is: the <mo>
element content between double quotes (start and end tags not shown),
followed by the attribute list in XML format, starting with the
form attribute, followed by the default rendering
attributes which should be used for mo elements
with the given content and form attribute.

Note that the characters & and < are represented in the
following table entries by the entity references
&amp; and &lt; respectively,
as would be necessary if they appeared in the content of an actual
mo element (or any other MathML or XML
element).

(note the lack of double quotes around the content, and the
whitespace added around the content for readability, which is optional
in MathML).

This entry means that, for MathML renderers which use this
suggested operator dictionary, giving the element
<mo form="prefix"> ( </mo>
alone, or simply
<mo> ( </mo>
in a position for which
form="prefix"
would be inferred (see below), is equivalent to giving the element
with all attributes as shown above.

F.2 Indexing of operator dictionary

Note that the dictionary is indexed not just by the element
content, but by the element content and form attribute
value, together. Operators with more than one possible form have more
than one entry. The MathML specification describes how the renderer
chooses ("infers") which form to use when no form
attribute is given; see Section 3.2.5.7.2 Default value of the
form attribute.

Having made that choice, or with the form attribute
explicitly specified in the <mo> element's start
tag, the MathML renderer uses the remaining attributes from the
dictionary entry for the appropriate single form of that operator,
ignoring the entries for the other possible forms.

F.3 Choice of entity names

Extended characters in MathML (and in the operator dictionary
below) are represented by XML-style entity references using the syntax
&character-name; the complete list of characters and
character names is given in Chapter 6 Characters, Entities and Fonts. Many characters can be referred
to by more than one name; often, memorable names composed of full
words have been provided in MathML, as well as one or more names used
in other standards, such as Unicode. The characters in the operators
in this dictionary are generally listed under their full-word names
when these exist. For example, the integral operator is named below by
the one-character sequence &Integral;, but
could equally well be named &int;. The choice
of name for a given character in MathML has no effect on its
rendering.

It is intended that every entity named below appears somewhere in
Chapter 6 Characters, Entities and Fonts. If this is not true, it is an error in this
specification. If such an error exists, the abovementioned chapter should
be taken as definitive, rather than this appendix.

F.4 Notes on lspace and
rspace attributes

The values for lspace and rspace given here range from 0 to
"verythickmathspace", which has a default value
of 6/18 em.
For the invisible operators whose content is &InvisibleTimes; or &ApplyFunction;,
it is suggested that MathML renderers choose spacing in a context-sensitive
way (which is an exception to the static values given in the following
table). For <mo>&ApplyFunction;</mo>, the total
spacing ("lspace"+"rspace") in
expressions such as "sin x" (where the right operand
doesn't start with a fence) should be greater than zero; for
<mo>&InvisibleTimes;</mo>, the total spacing
should be greater than zero when both operands (or the nearest tokens on
either side, if on the baseline) are identifiers displayed in a non-slanted
font (i.e. under the suggested rules, when both operands are
multi-character identifiers).

Some renderers may wish to use no spacing for most operators
appearing in scripts (i.e. when scriptlevel is greater
than 0; see Section 3.3.4 Style Change (mstyle)), as is the case in TEX.