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 that radical symbols not touching the base.

Improve lookup of char variants for large operators

Large operators are essentially stretched using size variants. The purpose of bug 584332 is to improve the selection of these variants. This is important now that we support STIX fonts and will help to prepare the support for the Asana Math font.

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. Also, the form infix/postfix/prefix is used to determine the properties of an operator. Hence, we need to implement the heuristic rules to determine the form of an operator.

See bug 562460

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

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

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

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

Failure of stretching

Stretching does not work on a MathML-only document

<math xmlns="http://www.w3.org/1998/Math/MathML">
  <mo>{</mo>
  <mfrac><mn>1</mn><mn>2</mn></mfrac>
</math>

or for direct children of the <math/> element

<math xmlns="http://www.w3.org/1998/Math/MathML">
  <mo>(</mo>
  <mfrac>
    <mfrac>
      <mi>a</mi>
      <mi>b</mi>
    </mfrac>
    <mfrac>
      <mn>c</mn>
      <mi>d</mi>
    </mfrac>
  </mfrac>
  <mo>)</mo>
</math>

See bug 442209, bug 585347.