MathML:Stretchy: Difference between revisions

 
(3 intermediate revisions by the same user not shown)
Line 1: Line 1:
== [DONE] Scale 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
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
[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 ==
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 [http://www.w3.org/TR/MathML3/appendixc.html 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 [http://www.w3.org/TR/MathML3/chapter3.html#presm.formdefval heuristic rules to determine the form] of an operator.
See {{bug|562460}}
Most entries have been upgraded in {{bug|534970}}. The [https://bugzilla.mozilla.org/show_bug.cgi?id=534970#c66 remaining differences] are for some diagonal arrows and bars.


==  [DONE] Embellished operators ==
==  [DONE] Embellished operators ==
Line 26: Line 14:
See {{bug|21479}}.
See {{bug|21479}}.


== Diagonal direction ==
== 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 [http://www.w3.org/TR/MathML3/appendixc.html 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 [https://bugzilla.mozilla.org/show_bug.cgi?id=534970#c66 remaining differences] are for some diagonal arrows and bars.


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).
Also, the form infix/postfix/prefix is used to determine the properties of an operator. We should implement the [http://www.w3.org/TR/MathML3/chapter3.html#presm.formdefval heuristic rules to better determine the form] of an operator (see {{bug|562460}}).


== Stretching in mtable cells ==
== Stretching in mtable cells ==
Line 49: Line 41:
See {{bug|236963}}
See {{bug|236963}}


== Failure of stretching ==
== Diagonal direction ==


Stretching does not work on a MathML-only document
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).
 
<pre>
<math xmlns="http://www.w3.org/1998/Math/MathML">
  <mo>{</mo>
  <mfrac><mn>1</mn><mn>2</mn></mfrac>
</math>
</pre>


or for direct children of the <math/> element
== Other bugs ==
 
<pre>
<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>
</pre>


See {{bug|442209}}, {{bug|585347}}.
See {{bug|442209}}, {{bug|585347}}, {{bug|666754}}, {{bug|687751}}, {{bug|687807}}
Confirmed users
226

edits