MathML:Stretchy

[DONE] Scale stretchy

For various reasons, stretching may be imperfect: the user's system lacks mathematical fonts, we do not support yet the stretching for a particular char or we do not have a glyph of suitable size. Using a scale transform bug 414277 would allow to workaround the issue of non-stretched characters and improve the accuracy of stretching. Note that as in TeX, an imperfect stretching causes issues such as radical symbols not touching the base.

[DONE] Embellished operators

There are specific stretchy rules for embellished operators that should be implemented. The remaining elements that we do not treat as embellished operators are:

• first element of a semantics
• mstyle, mphantom, or mpadded used as mrow.
• mrow whose arguments consist (in any order) of one embellished operator and zero or more space-like elements.

See bug 21479.

Operator dictionary and heuristic rules for the operator form

Many operator properties affecting stretching are provided by the MathML Operator Dictionary. We should upgrade our dictionary to the one given in MathML3, where a lot of new entries are added and several properties modified.

[edit] Most entries have been upgraded in bug 534970. The remaining differences are for some diagonal arrows and bars.

Also, the form infix/postfix/prefix is used to determine the properties of an operator. We should implement the heuristic rules to better determine the form of an operator (see bug 562460).

Stretching in mtable cells

When an operator is the sole direct subexpression of an mtd in a row/column of a mtable it should stretch to cover the maximum height/width of the non-stretchy direct sub-expressions in the mrow element. Here is a basic example (the brace should cover the height of the mfrac):

<mtable><mtr>
  <mtd><mo>{</mo></mtd>
  <mtd><mfrac><mi>a</mi><mi>b</mi></mfrac></mtd>
</mtr></mtable>

Of course, the general case is more complicated:

• there may be both vertical/horizontal stretching involved at the same time.
• there may be several non-stretchy direct sub-expressions.
• there may be columnspan/rowspan attributes
• and maybe more...

See bug 236963

Diagonal direction

The MathML spec mentions diagonal arrows as an example of characters that stretch both in vertical and horizontal directions. We already support stretching of horizontal/vertical arrows using a composite char. The idea of bug 552290 is to apply a rotation on this composite char to implement diagonal direction. We should add direction:updiagonal and direction:downdiagonal in our operator dictionary to distinguish this diagonal stretching. If we want a general mechanism, an attribute like basechar:\UNNNN should also be added to indicate on which char we should apply the rotation (i.e. a horizontal arrow in our case).

Other bugs

See bug 442209, bug 585347, bug 666754, bug 687751, bug 687807