MathML:Stretchy: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
Line 4: Line 4:
[http://www.mozilla.org/projects/mathml/screenshots/ex31.gif radical symbols not touching the base].
[http://www.mozilla.org/projects/mathml/screenshots/ex31.gif radical symbols not touching the base].


==  Improve lookup of char variants for large operators ==
Improve lookup of char variants for large operators


See {{bug|584332}}
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 ==
== Operator dictionary and heuristic rules for the operator form ==

Revision as of 14:54, 28 August 2010

[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 534970 and bug 562460

[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

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.

[fred] New patch pushed: first element of a semantics

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.