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

See bug 584332

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.

[fred] The operator dictionary uses the new syntax of MathML3

[fred] Our private "direction" property is available for any operators

[fred] New patch pushed: remove infix entries for N-ary Union and Intersection

[fred] New patch pushed: add entries for vertical and horizontal arrows

[fred] New patch pushed: add entries for stretchy fences

[fred] New patch pushed: make operator with a stretchy form use the same direction for all their forms

[fred] New patch pushed: add private data "integral"

[fred] New patch pushed: update some entries whose stretchiness has changed

See bug 534970 and bug 562460

Embellished operators

There are specific stretchy rules for embellished operators that should be implemented.

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.