Closed
Bug 519126
Opened 11 years ago
Closed 10 years ago
MathML Operator Dictionary: improve the syntax of mathfont.properties
Categories
(Core :: MathML, defect)
Core
MathML
Not set
Tracking
()
RESOLVED
FIXED
mozilla1.9.3a3
People
(Reporter: fredw, Assigned: fredw)
References
Details
Attachments
(2 files, 6 obsolete files)
2.57 KB,
application/xhtml+xml

Details  
88.29 KB,
patch

karlt
:
review+

Details  Diff  Splinter Review 
UserAgent: Mozilla/5.0 (X11; U; Linux i686; enUS; 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
Assignee  
Comment 1•11 years ago


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.
Updated•11 years ago

Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 2•11 years ago


(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/WDMathML320090924/chapter3.html#id.3.2.5.2
Assignee  
Comment 3•11 years ago


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
Assignee  
Updated•11 years ago

Blocks: scalestretchy
Assignee  
Comment 4•11 years ago


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/wwwmath/2009Sep/0039.html
Attachment #403492 
Attachment is obsolete: true
Assignee  
Updated•11 years ago

Attachment #404416 
Flags: review?(mozbugz)
Assignee  
Comment 5•11 years ago


Attachment #406264 
Flags: review?(mozbugz)
Comment 6•11 years ago


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 # ∥ >+operator.\u2225.postfix = direction:vertical stretchy fence lspace:.0em rspace :.0em # ∥ >+operator.\u2016.prefix = direction:vertical stretchy fence lspace:.0em rspace: .0em # ‖ ‖ >+operator.\u2016.postfix = direction:vertical stretchy fence lspace:.0em rspace :.0em # ‖ ‖ >+operator.\u2223.prefix = direction:vertical stretchy fence lspace:.0em rspace: .0em # ∣ >+operator.\u2223.postfix = direction:vertical stretchy fence lspace:.0em rspace :.0em # ∣ >+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 # ⎰ ⎰ >+operator.\u23B1.postfix = direction:vertical stretchy fence lspace:0em rspace:0em # ⎱ ⎱ 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 nonfence operators too that I think maybe should be symmetric: >+operator.\u2294.infix = direction:vertical stretchy lspace:mediummathspace rspace:mediummathspace # ⊔ >+operator.\u22C3.infix = direction:vertical stretchy lspace:mediummathspace rspace:mediummathspace # ⋃ >+operator.\u228E.infix = direction:vertical stretchy lspace:mediummathspace rspace:mediummathspace # ⊎ >+operator.\u22C2.infix = direction:vertical stretchy lspace:mediummathspace rspace:mediummathspace # ⋂ >+operator.\u2293.infix = direction:vertical stretchy lspace:mediummathspace rspace:mediummathspace # ⊓ Some of these have prefix forms that are symmetric. >+operator.\u2296.prefix = largeop movablelimits lspace:0em rspace:thinmathspace # ⊖ >+operator.\u2295.prefix = largeop movablelimits lspace:0em rspace:thinmathspace # ⊕ >+operator.\u228E.prefix = direction:vertical stretchy largeop movablelimits lspace:0em rspace:thinmathspace # ⊎ >+operator.\u2A04.prefix = direction:vertical stretchy largeop movablelimits lspace:0em rspace:thinmathspace # ⨄ >+operator.\u2A06.prefix = direction:vertical stretchy largeop movablelimits lspace:0em rspace:thinmathspace # ⨆ These seem similar to Union and Sum which are symmetric. >+operator.\u2297.prefix = largeop movablelimits lspace:0em rspace:thinmathspace # ⊗ >+operator.\u2299.prefix = largeop movablelimits lspace:0em rspace:thinmathspace # ⊙ Also similar to Union and Sum, I guess. >+operator.\u2216.infix = direction:vertical stretchy lspace:thinmathspace rspace:thinmathspace # ∖ >+operator.\u002F.infix = direction:vertical stretchy lspace:thinmathspace rspace:thinmathspace # / Not sure what's best here.
Comment 7•11 years ago


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.)
Comment 8•11 years ago


http://hg.mozilla.org/mozillacentral/annotate/4046f3843bdb/layout/mathml/nsMathMLmoFrame.cpp#l806
Assignee  
Comment 9•11 years ago


(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 nonfence 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.
Assignee  
Comment 10•11 years ago


(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/mozillacentral/annotate/4046f3843bdb/layout/mathml/nsMathMLmoFrame.cpp#l806 How do you think operator and requested container should be aligned? using the baselines? the vertical centers?
Assignee  
Comment 11•11 years ago


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  
Updated•11 years ago

Assignee: nobody → fred.wang
Status: NEW → ASSIGNED
Comment 12•11 years ago


(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.
Comment 13•11 years ago


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
Comment 14•11 years ago


(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 largeoponly 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.
Assignee  
Comment 15•11 years ago


> "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/mozillacentral/source/layout/mathml/nsMathMLOperators.cpp#167 and there is an additional case for [length] values (actually, only used for "0em"): http://mxr.mozilla.org/mozillacentral/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;
Assignee  
Updated•11 years ago

Attachment #406969 
Attachment is patch: false
Attachment #406969 
Attachment mime type: text/plain → application/xhtml+xml
Assignee  
Comment 16•11 years ago


> 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.mathfontfamily (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...
Assignee  
Comment 17•11 years ago


> (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.
Assignee  
Comment 18•11 years ago


What about this patch?
Assignee  
Updated•11 years ago

Attachment #404416 
Attachment is obsolete: true
Attachment #404416 
Flags: review?(mozbugz)
Assignee  
Updated•11 years ago

Attachment #406264 
Flags: review?(mozbugz)
Comment 19•11 years ago


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.
Assignee  
Comment 20•11 years ago


Attachment #406264 
Attachment is obsolete: true
Attachment #407155 
Attachment is obsolete: true
Assignee  
Comment 21•11 years ago


> >+operator.\u2225.prefix = direction:vertical stretchy fence lspace:.0em rspace: > .0em # ∥ > >+operator.\u2225.postfix = direction:vertical stretchy fence lspace:.0em rspace > :.0em # ∥ > >+operator.\u2016.prefix = direction:vertical stretchy fence lspace:.0em rspace: > .0em # ‖ ‖ > >+operator.\u2016.postfix = direction:vertical stretchy fence lspace:.0em rspace > :.0em # ‖ ‖ > >+operator.\u2223.prefix = direction:vertical stretchy fence lspace:.0em rspace: > .0em # ∣ > >+operator.\u2223.postfix = direction:vertical stretchy fence lspace:.0em rspace > :.0em # ∣ > >+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 # ⎰ ⎰ > >+operator.\u23B1.postfix = direction:vertical stretchy fence lspace:0em rspace:0em # ⎱ ⎱ > > 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 nonfence operators too that I think maybe should be symmetric: > > >+operator.\u2294.infix = direction:vertical stretchy lspace:mediummathspace rspace:mediummathspace # ⊔ > >+operator.\u22C3.infix = direction:vertical stretchy lspace:mediummathspace rspace:mediummathspace # ⋃ > >+operator.\u228E.infix = direction:vertical stretchy lspace:mediummathspace rspace:mediummathspace # ⊎ > >+operator.\u22C2.infix = direction:vertical stretchy lspace:mediummathspace rspace:mediummathspace # ⋂ > >+operator.\u2293.infix = direction:vertical stretchy lspace:mediummathspace rspace:mediummathspace # ⊓ > > 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 # ⊖ > >+operator.\u2295.prefix = largeop movablelimits lspace:0em rspace:thinmathspace # ⊕ > >+operator.\u228E.prefix = direction:vertical stretchy largeop movablelimits lspace:0em rspace:thinmathspace # ⊎ > >+operator.\u2A04.prefix = direction:vertical stretchy largeop movablelimits lspace:0em rspace:thinmathspace # ⨄ > >+operator.\u2A06.prefix = direction:vertical stretchy largeop movablelimits lspace:0em rspace:thinmathspace # ⨆ > > These seem similar to Union and Sum which are symmetric. > I made them symmetric. > >+operator.\u2297.prefix = largeop movablelimits lspace:0em rspace:thinmathspace # ⊗ > >+operator.\u2299.prefix = largeop movablelimits lspace:0em rspace:thinmathspace # ⊙ > > Also similar to Union and Sum, I guess. > > >+operator.\u2216.infix = direction:vertical stretchy lspace:thinmathspace rspace:thinmathspace # ∖ > >+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.
Assignee  
Comment 22•11 years ago


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.
Assignee  
Comment 23•11 years ago


> >+operator.\u2297.prefix = largeop movablelimits lspace:0em rspace:thinmathspace # ⊗
> >+operator.\u2299.prefix = largeop movablelimits lspace:0em rspace:thinmathspace # ⊙
>
> Also similar to Union and Sum, I guess.
I also made them symmetric.
Assignee  
Updated•11 years ago

Blocks: nsStretchDirection
Assignee  
Updated•11 years ago

No longer blocks: scalestretchy
Assignee  
Comment 24•10 years ago


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 noninteger values are forbidden)?
Comment 25•10 years ago


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.
Assignee  
Updated•10 years ago

Attachment #407845 
Flags: review?(mozbugz)
Updated•10 years ago

Attachment #407845 
Flags: review?(karlt) → review+
Comment 27•10 years ago


http://hg.mozilla.org/mozillacentral/rev/4f08c0415dad
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Keywords: checkinneeded
Resolution:  → FIXED
Target Milestone:  → mozilla1.9.3a3
You need to log in
before you can comment on or make changes to this bug.
Description
•