Closed Bug 519126 Opened 11 years ago Closed 10 years ago

MathML Operator Dictionary: improve the syntax of mathfont.properties

Categories

(Core :: MathML, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla1.9.3a3

People

(Reporter: fredw, Assigned: fredw)

References

Details

Attachments

(2 files, 6 obsolete files)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20090927 Minefield/3.7a1pre
Build Identifier: 

At the moment, a typical entry in the operator dictionary is:

operator.\u22C1.prefix = stretchy:vertical largeop:true movablelimits:true lspace:0em rspace:thinmathspace # ⋁

The syntax for the "stretchy" property does not really match the one of MathML Operator Dictionary, where "stretchy" is only a boolean, not a direction. Moreover this only allows to assign a direction for default stretchy operator. We must also always indicate the value of boolean properties, while this is not useful since the value is always "true". Hence I suggest this new syntax:

operator.\u22C1.prefix = direction:vertical strechy largeop movablelimits lspace:0em rspace:thinmathspace # ⋁

Reproducible: Always
This patch applies the changes announced above for mathfont.properties and modifies the parser accordingly. It also adds the property "symmetric" for some operators, with respect to MathML 3 (note that in the current working draft, this property is no longer "true" by default). BTW, it seems that the parser accepts "=" in place of ":", even if this option is not used and should maybe be removed.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to comment #1)
> It also adds the property "symmetric" for some operators, with respect to
> MathML 3 (note that in the current working draft, this property is no longer
> "true" by default).

It seems to be true by default here:
http://www.w3.org/TR/2009/WD-MathML3-20090924/chapter3.html#id.3.2.5.2
Attached patch improvements (obsolete) — Splinter Review
I think my changes were correct. They only deals with the operators that are in the dictionary: at the end "symmetric" is set to true iff this property is listed explicitly. However, it seems that the current implementation does not set "symmetric" to true when the operator is not is the dictionary. Similarly the value for left and right space is not set by default to thickmathspace. I integrated fixes for this to the patch.
Attachment #403139 - Attachment is obsolete: true
Finally setting thickmathspace as the default produces strange spacing, so let's not doing it for the moment. Also, it looks like the Math WG is going to remove the requirement in chapter 3 that the default value of symmetric is "true":

http://lists.w3.org/Archives/Public/www-math/2009Sep/0039.html
Attachment #403492 - Attachment is obsolete: true
Attachment #404416 - Flags: review?(mozbugz)
Attached patch remove the whitespace changes (obsolete) — Splinter Review
Attachment #406264 - Flags: review?(mozbugz)
Comment on attachment 406264 [details] [diff] [review]
remove the whitespace changes

>-  NS_MATHML_OPERATOR_STRETCHY           = 0xC,
>-  NS_MATHML_OPERATOR_STRETCHY_VERT        = 1<<2,
>-  NS_MATHML_OPERATOR_STRETCHY_HORIZ       = 1<<3,
>+  NS_MATHML_OPERATOR_DIRECTION            = 0xC,
>+  NS_MATHML_OPERATOR_DIRECTION_HORIZONTAL = 1<<2,
>+  NS_MATHML_OPERATOR_DIRECTION_VERTICAL   = 2<<2,
>   // other bits used in the Operator Dictionary
>-  NS_MATHML_OPERATOR_FENCE              = 1<<4,
>+  NS_MATHML_OPERATOR_STRETCHY           = 1<<4,

I liked 1<<3 better than 2<<2, unless perhaps you would like to also change
NS_MATHML_OPERATOR_DIRECTION to 0x3<<2.

>+#define NS_MATHML_OPERATOR_IS_DIRECTION_VERTICAL(_flags) \
>+  (NS_MATHML_OPERATOR_DIRECTION_VERTICAL == ((_flags) & NS_MATHML_OPERATOR_DIRECTION))
>+
>+#define NS_MATHML_OPERATOR_IS_DIRECTION_HORIZONTAL(_flags) \
>+  (NS_MATHML_OPERATOR_DIRECTION_HORIZONTAL == ((_flags) & NS_MATHML_OPERATOR_DIRECTION))

Would changing _IS_ to _HAS_ make sense because more than one direction may be
present?  Or would you prefer to leave that until more than one direction is
implemented?

>     OperatorData* data = gStretchyOperatorArray->ElementAt(aIndex);
>     if (data) {
>-      if (NS_MATHML_OPERATOR_IS_STRETCHY_VERT(data->mFlags))
>-        return NS_STRETCH_DIRECTION_VERTICAL;
>-      else if (NS_MATHML_OPERATOR_IS_STRETCHY_HORIZ(data->mFlags))
>-        return NS_STRETCH_DIRECTION_HORIZONTAL;
>+      if (NS_MATHML_OPERATOR_IS_STRETCHY(data->mFlags)) {
>+        if (NS_MATHML_OPERATOR_IS_DIRECTION_VERTICAL(data->mFlags))
>+          return NS_STRETCH_DIRECTION_VERTICAL;
>+        else if (NS_MATHML_OPERATOR_IS_DIRECTION_HORIZONTAL(data->mFlags))
>+          return NS_STRETCH_DIRECTION_HORIZONTAL;
>+      }

I don't think its necessary to test NS_MATHML_OPERATOR_IS_STRETCHY here as the
operator wouldn't be in gStretchyOperatorArray if it were not stretchy.

>+operator.\u2225.prefix = direction:vertical stretchy fence lspace:.0em rspace:
.0em # &DoubleVerticalBar;
>+operator.\u2225.postfix = direction:vertical stretchy fence lspace:.0em rspace
:.0em # &DoubleVerticalBar;
>+operator.\u2016.prefix = direction:vertical stretchy fence lspace:.0em rspace:
.0em # &Vert; &Verbar;
>+operator.\u2016.postfix = direction:vertical stretchy fence lspace:.0em rspace
:.0em # &Vert; &Verbar;
>+operator.\u2223.prefix = direction:vertical stretchy fence lspace:.0em rspace:
.0em # &VerticalBar;
>+operator.\u2223.postfix = direction:vertical stretchy fence lspace:.0em rspace
:.0em # &VerticalBar;
>+operator.\u007C.prefix = direction:vertical stretchy fence lspace:.0em rspace:
.0em # |
>+operator.\u007C.postfix = direction:vertical stretchy fence lspace:.0em rspace
:.0em # |

>+operator.\u23B0.prefix = direction:vertical stretchy fence lspace:0em rspace:0em # &lmoustache; &lmoust;
>+operator.\u23B1.postfix = direction:vertical stretchy fence lspace:0em rspace:0em # &rmoustache; &rmoust;

These few fence operators that are not symmetric.
I don't actually know why fences should be symmetric, but if most are then I
guess these should be too?

operator.\u007C.infix is symmetric.  I think prefix, postfix, and infix should
probably all be the same. 

I wonder whether operator.\u2223.infix and operator.\u2225.infix (and perhaps
operator.\u2016.infix) should be symmetric too?

There are a few non-fence operators too that I think maybe should be symmetric:

>+operator.\u2294.infix = direction:vertical stretchy lspace:mediummathspace rspace:mediummathspace # &SquareUnion;
>+operator.\u22C3.infix = direction:vertical stretchy lspace:mediummathspace rspace:mediummathspace # &Union;
>+operator.\u228E.infix = direction:vertical stretchy lspace:mediummathspace rspace:mediummathspace # &UnionPlus;
>+operator.\u22C2.infix = direction:vertical stretchy lspace:mediummathspace rspace:mediummathspace # &Intersection;
>+operator.\u2293.infix = direction:vertical stretchy lspace:mediummathspace rspace:mediummathspace # &SquareIntersection;

Some of these have prefix forms that are symmetric.

>+operator.\u2296.prefix = largeop movablelimits lspace:0em rspace:thinmathspace # &CircleMinus;
>+operator.\u2295.prefix = largeop movablelimits lspace:0em rspace:thinmathspace # &CirclePlus;
>+operator.\u228E.prefix = direction:vertical stretchy largeop movablelimits lspace:0em rspace:thinmathspace # &UnionPlus;
>+operator.\u2A04.prefix = direction:vertical stretchy largeop movablelimits lspace:0em rspace:thinmathspace # &biguplus;
>+operator.\u2A06.prefix = direction:vertical stretchy largeop movablelimits lspace:0em rspace:thinmathspace # &bigsqcup;

These seem similar to Union and Sum which are symmetric.

>+operator.\u2297.prefix = largeop movablelimits lspace:0em rspace:thinmathspace # &CircleTimes;
>+operator.\u2299.prefix = largeop movablelimits lspace:0em rspace:thinmathspace # &CircleDot;

Also similar to Union and Sum, I guess.

>+operator.\u2216.infix = direction:vertical stretchy lspace:thinmathspace rspace:thinmathspace # &Backslash;
>+operator.\u002F.infix = direction:vertical stretchy lspace:thinmathspace rspace:thinmathspace # /

Not sure what's best here.
I fear that any operator that is not symmetric and doesn't stretch to its requested height (including largeop operators) is going to be bottom aligned with the requested container, which doesn't seem right.  Can you check this, please?  (Previously, we wouldn't have noticed because most things are symmetric.)
(In reply to comment #6)

> I liked 1<<3 better than 2<<2, unless perhaps you would like to also change
> NS_MATHML_OPERATOR_DIRECTION to 0x3<<2.
> 
> Would changing _IS_ to _HAS_ make sense because more than one direction may be
> present?  Or would you prefer to leave that until more than one direction is
> implemented?

At the moment, my idea is to have four directions:

- '0<<2' default or "both" (stretch in any direction)
- 1<<2 horizontal
- 2<<2 vertical
- 3<<2 diagonal

	That's why I keep the "is" and use <<2 (which seems clearer to me than 1<<2, 1<<3, 3<<2). However for the moment, I think we can keep 1<<3.

	In the sense of the spec, "diagonal" and "both" would be the same. But to implement the diagonal arrows correctly, I think we have to make this subtle distinction. A diagonal arrow would be a horizontal arrow stretched horizontally to the length of the diagonal (either with a set of glyphs or with a scale) and then rotated to move the horizontal axis to the diagonal. In my opinion, this would give a much better result than a combination of vertical & horizontal scales.

> I don't think its necessary to test NS_MATHML_OPERATOR_IS_STRETCHY here as the
> operator wouldn't be in gStretchyOperatorArray if it were not stretchy.

	I think you are right. BTW, it seems that the direction is currently only accessible for operators in gStretchyOperatorArray. However, this patch is only for the parsing level so I have not checked how we need to change this (maybe gStretchyOperatorArray will no longer be needed?).
	
> These few fence operators that are not symmetric.
> I don't actually know why fences should be symmetric, but if most are then I
> guess these should be too?
> operator.\u007C.infix is symmetric.  I think prefix, postfix, and infix should
> probably all be the same. 
> I wonder whether operator.\u2223.infix and operator.\u2225.infix (and perhaps
> operator.\u2016.infix) should be symmetric too?
> There are a few non-fence operators too that I think maybe should be symmetric:
> Some of these have prefix forms that are symmetric.
> These seem similar to Union and Sum which are symmetric.
> Also similar to Union and Sum, I guess.
> Not sure what's best here.

	I admit that I have not really thought about these issues. I simply made some "replace all"'s (something like ":true" => "", "strechy:vertical" => "direction:vertical stretchy", "strechy:horizontal" => "direction:horizontal stretchy"). For this patch, I think it's OK to only change the syntax. Then I would be tempted by the lazy solution: trust the Math WG and just made an automatic conversion from their updated operator dictionary (we would still need to deal with the "direction" though). The improvements of this patch would make this conversion easier. BTW, in the MathML3 operator dictionary, lspace & rspace are now represented by digit from 0 to 7 rather than "*mathspace". Maybe this patch is also the occasion to change this. They also added a "priority" value, but I'm not sure it would be useful for a rendering engine.
(In reply to comment #7)
> I fear that any operator that is not symmetric and doesn't stretch to its
> requested height (including largeop operators) is going to be bottom aligned
> with the requested container, which doesn't seem right.  Can you check this,
> please?  (Previously, we wouldn't have noticed because most things are
> symmetric.)

(In reply to comment #8)
> http://hg.mozilla.org/mozilla-central/annotate/4046f3843bdb/layout/mathml/nsMathMLmoFrame.cpp#l806

How do you think operator and requested container should be aligned? using the baselines? the vertical centers?
In the case symmetric="false", I suppose the vertical bar should have its
center aligned with the centers of red mspace's, but here the bottoms are
aligned.
Assignee: nobody → fred.wang
Status: NEW → ASSIGNED
(In reply to comment #9)
> At the moment, my idea is to have four directions:
> 
> - '0<<2' default or "both" (stretch in any direction)
> - 1<<2 horizontal
> - 2<<2 vertical
> - 3<<2 diagonal
> 
>     That's why I keep the "is" and use <<2 (which seems clearer to me than
> 1<<2, 1<<3, 3<<2). However for the moment, I think we can keep 1<<3.

The old NS_MATHML_OPERATOR_IS_STRETCHY_VERT was really a _HAS_ because it only
tested one bit.  If NS_MATHML_OPERATOR_IS_DIRECTION_VERTICAL tests both bits then _IS_ is the correct name.

0<<2 looked like a "none" to me and I thought 1&2 = 3 looked like a "both", but
its not that important to me.  2<<2 makes sense with an _IS_ test.

"both" and "diagonal" do seem different to me and "both" might really be
"either".  I understand that diagonal can be done better than a simple stretch
in both directions, though I imagine another bit would be needed to indicate
which diagonal.  This is not a decision that needs to be made now anyway.

If you use _IS_ and 2<<2 though can you also change
NS_MATHML_OPERATOR_DIRECTION from 0xC to 0x3<<2, please?

> BTW, it seems that the direction is currently only accessible for operators
> in gStretchyOperatorArray. However, this patch is only for the parsing level
> so I have not checked how we need to change this (maybe
> gStretchyOperatorArray will no longer be needed?).

Yes, I don't know why gStretchyOperatorArray is there.	I would expect one
array to be sufficient.

>     I admit that I have not really thought about these issues. I simply made
> some "replace all"'s (something like ":true" => "", "strechy:vertical" =>
> "direction:vertical stretchy", "strechy:horizontal" => "direction:horizontal
> stretchy"). For this patch, I think it's OK to only change the syntax. Then
> I would be tempted by the lazy solution: trust the Math WG and just made an
> automatic conversion from their updated operator dictionary (we would still
> need to deal with the "direction" though). The improvements of this patch
> would make this conversion easier.

I like the change in syntax, and merely a change in syntax would be good,
except that the default value for symmetric is also changed.

If the default value for symmetric is being changed from true to false then I
want to make sure:

1) That our symmetric="false" code, works reasonably.  It probably hasn't been
   well used to date.

2) That operators that should default to symmetric don't change to asymmetric.

It seems that the WG has only recently changed the default value for
symmetric, so authors would not be expecting this change, and I don't know
whether any implementation has actually tried out this change.

> BTW, in the MathML3 operator dictionary, lspace & rspace are now represented
> by digit from 0 to 7 rather than "*mathspace". Maybe this patch is also the
> occasion to change this. They also added a "priority" value, but I'm not
> sure it would be useful for a rendering engine.

I haven't thought much about this syntax difference.  If it is a sensible
change to make, I'd prefer it was made in a separate patch, if reasonably
possible.
Thanks for the testcase.  I've modified it a bit because "|" actually stretches to the requested height, so that's not really an issue.

If you apply attachment 406966 [details] [diff] [review], then this testcase demonstrates what I was
concerned about.

Entering "⟨" for the operator gives another example (if attachment 406966 [details] [diff] [review] is applied).
Attachment #406780 - Attachment is obsolete: true
(In reply to comment #10)
> How do you think operator and requested container should be aligned? using the
> baselines? the vertical centers?

If the container indicates the desired stretch size, then vertically centering
against the container should work reasonably well most of the time I expect.

For largeops with stretchy="false", the container size is not meaningful, and
I guess the symmetric attribute should not affect the position.  Baseline
alignment would be best here I think, though I haven't checked whether the
ascents from the nsMathMLChar are good.  (They don't make much sense when
building from parts, but largeop-only stretches don't build from parts IIRC.)

If it is not possible to get good baselines from largeop stretches, then maybe
doing something similar to symmetric makes sense.
> "both" and "diagonal" do seem different to me and "both" might really be
> "either".  I understand that diagonal can be done better than a simple stretch
> in both directions, though I imagine another bit would be needed to indicate
> which diagonal.  This is not a decision that needs to be made now anyway.
> 
> If you use _IS_ and 2<<2 though can you also change
> NS_MATHML_OPERATOR_DIRECTION from 0xC to 0x3<<2, please?

Yes, the "default" rather means "either". And you're right that at least one additional bit would be needed. I'll replace 0xC by 0x3<<2.

> I haven't thought much about this syntax difference.  If it is a sensible
> change to make, I'd prefer it was made in a separate patch, if reasonably
> possible.

Currently, the *mathspace names are converted to a digit between 1 and 7:

http://mxr.mozilla.org/mozilla-central/source/layout/mathml/nsMathMLOperators.cpp#167

and there is an additional case for [length] values (actually, only used for "0em"):

http://mxr.mozilla.org/mozilla-central/source/layout/mathml/nsMathMLOperators.cpp#161

In their new version of the dictionary, the Math WG directly uses a digit from 0 to 7. Hence I simply suggest to make the same in mathfont.properties and to replace all the previous code by something like:

if (aValue.Length() == 1 && nsCRT::IsAsciiDigit(aValue[0]))
  space = float(aValue[0])/float(18);
else return;
Attachment #406969 - Attachment is patch: false
Attachment #406969 - Attachment mime type: text/plain → application/xhtml+xml
> Thanks for the testcase.  I've modified it a bit because "|" actually stretches
> to the requested height, so that's not really an issue.
> 
> If you apply attachment 406966 [details] [diff] [review], then this testcase demonstrates what I was
> concerned about.
> 
> Entering "⟨" for the operator gives another example (if attachment 406966 [details] [diff] [review] is
> applied).

"|" was slightly taller than the requested size for small height, but I think I disabled font.mathfont-family (I got something similar to your "(" testcase). Anyway it was not really obvious and I was not able to find a vertical operator that shows the bug as clearly as your "Sum" example. So I guess a fix to this issue must be included in this patch...
> (I got something similar to your "(" testcase).

Sorry I misread your comment. Of course the "Left Angle Bracket" also shows clearly the bug. I've still a slight difference of size with the "Left Parenthesis" but I don't think it's a related issue.
What about this patch?
Attachment #404416 - Attachment is obsolete: true
Attachment #404416 - Flags: review?(mozbugz)
Attachment #406264 - Flags: review?(mozbugz)
Comment on attachment 407155 [details] [diff] [review]
Fix vertical alignment for strechy ops

>+      PRUint32 stretchHint =
>+        GetStretchHint(mFlags, mPresentationData, isVertical);

GetStretchHint() was already called once in this function.
By moving the declaration of stretchHint outside "if (useMathMLChar)", it can be reused here.  The GetStretchHint() call to set stretchHint can still be within "if (useMathMLChar)".

The rest looks good, thanks.
Attachment #406264 - Attachment is obsolete: true
Attachment #407155 - Attachment is obsolete: true
> >+operator.\u2225.prefix = direction:vertical stretchy fence lspace:.0em rspace:
> .0em # &DoubleVerticalBar;
> >+operator.\u2225.postfix = direction:vertical stretchy fence lspace:.0em rspace
> :.0em # &DoubleVerticalBar;
> >+operator.\u2016.prefix = direction:vertical stretchy fence lspace:.0em rspace:
> .0em # &Vert; &Verbar;
> >+operator.\u2016.postfix = direction:vertical stretchy fence lspace:.0em rspace
> :.0em # &Vert; &Verbar;
> >+operator.\u2223.prefix = direction:vertical stretchy fence lspace:.0em rspace:
> .0em # &VerticalBar;
> >+operator.\u2223.postfix = direction:vertical stretchy fence lspace:.0em rspace
> :.0em # &VerticalBar;
> >+operator.\u007C.prefix = direction:vertical stretchy fence lspace:.0em rspace:
> .0em # |
> >+operator.\u007C.postfix = direction:vertical stretchy fence lspace:.0em rspace
> :.0em # |
> 
> >+operator.\u23B0.prefix = direction:vertical stretchy fence lspace:0em rspace:0em # &lmoustache; &lmoust;
> >+operator.\u23B1.postfix = direction:vertical stretchy fence lspace:0em rspace:0em # &rmoustache; &rmoust;
> 
> These few fence operators that are not symmetric.
> I don't actually know why fences should be symmetric, but if most are then I
> guess these should be too?
> 
> operator.\u007C.infix is symmetric.  I think prefix, postfix, and infix should
> probably all be the same. 
> 
> I wonder whether operator.\u2223.infix and operator.\u2225.infix (and perhaps
> operator.\u2016.infix) should be symmetric too?
> 

In MathML 3 dictionary, all fences are symmetric except the quotes. I would also make Ceiling/Floor/Moustache nonsymmetric, since their shapes are not symmetric, but MathML 3 dictionary declares Ceiling and Floor as symmetric. Hence in the new patch all fences but quotes are symmetric.

> There are a few non-fence operators too that I think maybe should be symmetric:
> 
> >+operator.\u2294.infix = direction:vertical stretchy lspace:mediummathspace rspace:mediummathspace # &SquareUnion;
> >+operator.\u22C3.infix = direction:vertical stretchy lspace:mediummathspace rspace:mediummathspace # &Union;
> >+operator.\u228E.infix = direction:vertical stretchy lspace:mediummathspace rspace:mediummathspace # &UnionPlus;
> >+operator.\u22C2.infix = direction:vertical stretchy lspace:mediummathspace rspace:mediummathspace # &Intersection;
> >+operator.\u2293.infix = direction:vertical stretchy lspace:mediummathspace rspace:mediummathspace # &SquareIntersection;
> 
> Some of these have prefix forms that are symmetric.

I think the prefix/infix forms are really used differently: for instance the prefix Union is used to take the union for a family (that may be infinite) of sets while the infix Union is just a binary operation on two sets. It makes sense to me if they don't have the same properties. In MathML 3 dictionary, the prefix are declared "largeop movablelimits symmetric" while infix do not have any property.

> 
> >+operator.\u2296.prefix = largeop movablelimits lspace:0em rspace:thinmathspace # &CircleMinus;
> >+operator.\u2295.prefix = largeop movablelimits lspace:0em rspace:thinmathspace # &CirclePlus;
> >+operator.\u228E.prefix = direction:vertical stretchy largeop movablelimits lspace:0em rspace:thinmathspace # &UnionPlus;
> >+operator.\u2A04.prefix = direction:vertical stretchy largeop movablelimits lspace:0em rspace:thinmathspace # &biguplus;
> >+operator.\u2A06.prefix = direction:vertical stretchy largeop movablelimits lspace:0em rspace:thinmathspace # &bigsqcup;
> 
> These seem similar to Union and Sum which are symmetric.
> 

I made them symmetric.

> >+operator.\u2297.prefix = largeop movablelimits lspace:0em rspace:thinmathspace # &CircleTimes;
> >+operator.\u2299.prefix = largeop movablelimits lspace:0em rspace:thinmathspace # &CircleDot;
> 
> Also similar to Union and Sum, I guess.
> 
> >+operator.\u2216.infix = direction:vertical stretchy lspace:thinmathspace rspace:thinmathspace # &Backslash;
> >+operator.\u002F.infix = direction:vertical stretchy lspace:thinmathspace rspace:thinmathspace # /
> 
> Not sure what's best here.

Let's do not change this, then. MathML 3 dictionary does not give them any properties.
Currently, mathfont.properties uses "0em" and ".0em" (the later is not actually supposed to be recognized by the parser but at the end it seems that all "if" cases are skip and 0 is set). The patch contains the announced simplification for the rspace/lspace, and in particular simply uses "0" for these spaces.

This patch also includes the fix for the vertical alignment of stretchy ops.
> >+operator.\u2297.prefix = largeop movablelimits lspace:0em rspace:thinmathspace # &CircleTimes;
> >+operator.\u2299.prefix = largeop movablelimits lspace:0em rspace:thinmathspace # &CircleDot;
> 
> Also similar to Union and Sum, I guess.

I also made them symmetric.
No longer blocks: scale-stretchy
The MathML 3 dictionary uses an integer x from 0 to 7 to indicate a space of x / 18 em. This is what I make for the parsing:

+    // aValue is assumed to be a digit from 0 to 7
+    PRInt32 error = 0;
+    float space = aValue.ToFloat(&error) / 18.0;
+    if (error) return;

would it be better to use space = aValue.ToInteger(&error) / 18.0 (so that non-integer values are forbidden)?
ToFloat seems fine, I think.  It allows Gecko's dictionary to represent the values that appear in the MathML3 suggested dictionary, while still allowing some finer adjustment should we ever want it.
Attachment #407845 - Flags: review?(mozbugz)
Attachment #407845 - Flags: review?(karlt) → review+
Thanks for the review!
Keywords: checkin-needed
http://hg.mozilla.org/mozilla-central/rev/4f08c0415dad
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a3
You need to log in before you can comment on or make changes to this bug.