This document has been moved to a MathML Core specification.

This section is non-normative.

It is not clear how the DisplayOperatorMinHeight is supposed to be used or whether it is really reliable. More specifically, integral symbols (e.g. INTEGRAL U+222B) are typically taller than N-ary operators (e.g. N-ARY SUMMATION U+2211) so a unique minimal height may not always be enough to determine the display size. Suppose for example that the sum has three size variants: the base size of height 1em, the display size of height 2em and a bigger variant of height 3em. Suppose that the integral has three sizes: a base size of height 1em, a larger size variant of height 2em and a display size of height 3em. If DisplayOperatorMinHeight is less than 3em then it does not force the display size of the integral to be selected. If it is more than 3em then none of the available sizes satisfies the condition. How to interpret that? Should we pick the largest as a fallback? If it is 3em, the desired size will be selected for the integral in display size but the one selected for the sum in display size will be too large. A heuristic is proposed in section 3.2.4 to workaround limitations of DisplayOperatorMinHeight.

The OpenType MATH specification does not seem to take into account linebreaking. As explained in section 3.1.2 it is important in a HTML5 context to be able to determine the min-content width and the max-content width. However when an operator is stretched vertically to cover a target size, it is not possible to know the selected size variant or glyph assembly without knowing the target size and so the min-content and max-content widths can only be approximated. In practice, the width of the vertical operators is almost independent on its stretch size. Should that be a requirement of the OpenType MATH specification?

In section 3.3.9 we describe the MathML menclose element. This one contains many notations that are not mentioned in the OpenType MATH specification. Some rendering suggestions are given based on the value of OverbarRuleThickness but perhaps new values should be introduced in the MathConstants subtable to cover these notations.