The STIXSize* fonts contain variant glyph sizes for a number of characters, and some glyphs for building glyphs of arbitrary size. Currently mathfontSTIXSize1.properties has support for all these partial glyphs (I think), but only has entries for variant sized glyphs of radicals and horizontal brackets, parentheses, and braces. Entries should also be added to mathfontSTIXSize1.properties for other glyphs corresponding to a stretchy operators in mathfont.properties. I'm guessing we should also use the STIXIntDis.otf or STIXIntUpDis.otf font for a larger size variant of the integral glyph(s), and maybe also the small and regular fonts. The slanted integral is more consistent with STIXGeneral, but the upright is more consistent with the integral built from parts in STIXSize1. This would be best done in a separate mathfontFAMILYNAME.properties file. If we choose the upright fonts we could use STIXIntUpSma.otf or STIXIntUp.otf in mathml.css for the math font-family. Selecting the appropriate STIX integral font is difficult with the beta fonts because all the fonts have the same family and styles. (http://groups.google.com/group/mozilla.dev.tech.mathml/msg/6b98d4fd278545c9) I suspect there are also more entries that could be added to the STIXNonUnicode.properties files.

This patch just adds support for largeop sum and some sizes of angle brackets. (Sounds like some new STIX fonts might be out soon, so might be best to wait for them before making this change.)

(In reply to comment #1) > Created an attachment (id=406966) [details] > sum and angle brackets > > This patch just adds support for largeop sum and some sizes of angle brackets. > (Sounds like some new STIX fonts might be out soon, so might be best to wait > for them before making this change.) HA HA HA :-) The STIX Fonts Project is ALWAYS near release http://groups.google.com/group/comp.lang.lisp/msg/279b173169de9e57/ Check the latest news http://www.stixfonts.org/ Please do not delay making any changes based on the assumption that the STIX fonts will be released soon.

Comment on attachment 406966 [details] [diff] [review] sum and angle brackets Yes, I had wondered whether it was safe to comment. Fred, do you think we should take this?

(In reply to comment #3) > (From update of attachment 406966 [details] [diff] [review]) > Yes, I had wondered whether it was safe to comment. > > Fred, do you think we should take this? The only problem I see is what you mentioned in bug 519126 comment 7 (currently this issue is not visible because vertical operators either fail to stretch or stretch to the exact size). So I think it's OK to take this now if we include the fix we discuss in bug 519126 (see attachment 408720 [details] [diff] [review]).

Comment on attachment 406966 [details] [diff] [review] sum and angle brackets >+\u2211 = \uFFFD\uFFFD\uFFFD\uFFFD\uFFFD\u2211 # Sum >+ If we add a larger glyph for Sum, I think we should also do the same for the Product (\u0220F).

Comment on attachment 406966 [details] [diff] [review] sum and angle brackets (In reply to comment #6) > If we add a larger glyph for Sum, I think we should also do the same for the > Product (\u0220F). Fair comment. There are a number of other characters too but Product and perhaps Coproduct seem the common ones that may look inconsistent if we just modify Sum.

(In reply to comment #7) > Fair comment. There are a number of other characters too but Product and > perhaps Coproduct seem the common ones that may look inconsistent if we just > modify Sum. Sum and Product are used for operations on numbers. However, Product is also used for operations on sets (cartesian product) so we should also add for instance Union, Intersection and Circle Plus (direct sum of vector spaces). Again, Circle Plus is also used for operations on formulae (exclusive OR) so we should add And and Or... I think the simplest is to add all N-ARY operators that have a size one, once and for all. Fortunately, it looks like there are not so many: fred@localhost:~/Desktop$ grep -A1 stixsiz1sym.otf allGlyphs.html | grep N-ARY <td>DOUBLE-STRUCK N-ARY SUMMATION</td></tr><tr><td>02140</td> <td>N-ARY PRODUCT</td></tr><tr><td>0220F</td> <td>N-ARY COPRODUCT</td></tr><tr><td>02210</td> <td>N-ARY SUMMATION</td></tr><tr><td>02211</td> <td>N-ARY LOGICAL AND</td></tr><tr><td>022C1</td> <td>N-ARY LOGICAL OR</td></tr><tr><td>022C2</td> <td>N-ARY INTERSECTION</td></tr><tr><td>022C3</td> <td>N-ARY UNION</td></tr><tr><td>022C4</td> <td>N-ARY CIRCLED DOT OPERATOR</td></tr><tr><td>02A01</td> <td>N-ARY CIRCLED PLUS OPERATOR</td></tr><tr><td>02A02</td> <td>N-ARY CIRCLED TIMES OPERATOR</td></tr><tr><td>02A03</td> <td>N-ARY UNION OPERATOR WITH DOT</td></tr><tr><td>02A04</td> <td>N-ARY UNION OPERATOR WITH PLUS</td></tr><tr><td>02A05</td> <td>N-ARY SQUARE INTERSECTION OPERATOR</td></tr><tr><td>02A06</td> <td>N-ARY SQUARE UNION OPERATOR</td></tr><tr><td>02A07</td> <td>N-ARY TIMES OPERATOR</td></tr><tr><td>02A0A</td> <td>N-ARY WHITE VERTICAL BAR</td></tr></table> Hence I think we can add all these operators, except maybe "N-ARY WHITE VERTICAL BAR" (I don't think this one is an N-ARY op?). This would make this patch fix the bug 491370 of angle brackets and improve slightly the rendering of largeop (bug 518330). I think all the operators listed are largeop in MathML 3, but I'm not sure we currently have all of them in our dictionary and we will probably need to complete it. So I would suggest to wait that bug 519126 is fixed before making this change (and this will also prevent the issue I mentioned in comment 5).

Is it intended that this bug also address the issue with the varying width ^ characters on this page? http://www.mozilla.org/projects/mathml/start.xhtml Or, is there a separate bug for that?

(In reply to comment #9) > Is it intended that this bug also address the issue with the varying width ^ > characters on this page? > > http://www.mozilla.org/projects/mathml/start.xhtml > > Or, is there a separate bug for that? For hat accents, see bug 416065. I've not checked whether STIX fonts can help to solve this bug. However, the work for bug 414277 gives promising results.

Comment on attachment 412233 [details] [diff] [review] n-ary op + angle brackets [pushed] So I think we can take this patch now bug 519126 is fixed.

(In reply to comment #12) > (From update of attachment 412233 [details] [diff] [review]) > So I think we can take this patch now bug 519126 is fixed. I think it would be cool if this partial fix is checked-in because it helps fixing bug 491370 and bug 518330. (I hesitate marking it "checkin-needed" because the whole bug is not fixed yet)

Comment on attachment 412233 [details] [diff] [review] n-ary op + angle brackets [pushed] http://hg.mozilla.org/mozilla-central/rev/bcc0ebee4ac9

This should fix bug 416065 and bug 416140 (at least for small sizes). For the moment, I've not completed STIXNonUnicode with composite accents. You can test with attachment 439767 [details].

(In reply to comment #16) > Created an attachment (id=439767) [details] > Testcase Stretchy Accent (MathML 3) I wonder why the check mark is a "stretchy accent" in the operator dictionary. Is it a confusion with \widecheck in LaTeX?

Do you know why the majority of accents in the dictionary have "postfix" form? (In reply to comment #18) > I wonder why the check mark is a "stretchy accent" in the operator dictionary. > Is it a confusion with \widecheck in LaTeX? I wonder whether stretchy might come from "check mark"'s relationship to U+221a square root, though that would be a prefix operator and "check mark" is infix.

Comment on attachment 439769 [details] [diff] [review] Add more sizes for stretchy accents >+operator.\u007E.postfix = direction:horizontal stretchy accent lspace:0 rspace:0 # ~ tilde >+operator.\u005F.postfix = direction:horizontal stretchy accent lspace:0 rspace:0 # _ low line Note that there are already non-stretchy "infix" entries for these operators that are being used in attachment 439767 [details]. operator.\u007E.infix = lspace:2 rspace:2 # ~ operator.\u005F.infix = lspace:2 rspace:2 # _ >+\u203E = \uFFFD\uFFFD\uFFFD\uFFFD\uFFFD\u0305\u0305@2\u0305@3\u0305@4\u0305@5 # overline, COMBINING OVERLINE >+\u005F = \uFFFD\uFFFD\uFFFD\uFFFD\uFFFD\u0332\u0332@2\u0332@3\u0332@4\u0332@5 # _ low line, COMBINING LOW LINE Can these be stretched using mathfontUnicode.properties, as for U+00AF and U+0332? They would then not be dependent on STIX fonts. # OverBar is stretched with U+0305 COMBINING OVERLINE which "connects on left and right" \u00AF = \uFFFD\uFFFD\uFFFD\u0305\u00AF # OverBar #\u0305 doesn't appear to be referenced by the MathML spec \u0332 = \uFFFD\uFFFD\uFFFD\u0332\u0332 # COMBINING LOW LINE, UnderBar

> I wonder whether stretchy might come from "check mark"'s relationship to U+221a > square root, though that would be a prefix operator and "check mark" is infix. Actually, I think "check mark" is not a mathematical operator and should not be in the dictionary at all. I suspect to be a mistake because of the \widecheck in LaTeX (that would explain what it is an accent). I think the comment in unicode is just to warn people that there are two characters that look the same but are used in a different context. > Note that there are already non-stretchy "infix" entries for these operators What do you mean? From bug 519126 comment 7, I think you want all the forms to have similar properties. I disagree, we should really handle operators differently according to its form. Here is what the spec says: http://www.w3.org/TR/MathML3/chapter3.html#presm.formdefval We do something more or less similar here: http://mxr.mozilla.org/mozilla-central/source/layout/mathml/nsMathMLmoFrame.cpp#367 however, we also do something here that does not seem correct: http://mxr.mozilla.org/mozilla-central/source/layout/mathml/nsMathMLmoFrame.cpp#199 Apart from the fact that LookupOperators does not work as expected (bug 524275), we are also merging the flags of all the different forms. This does not make sense to me, we should really determine the form using the spec's rules and then keep the corresponding flags. > Do you know why the majority of accents in the dictionary have "postfix" form? Probably because, when they are used as the last element of munder/mover/munderover, they are postfix. Otherwise, the other rules of the spec to determine the form (for example when the operator has only one form) should probably help finding the right properties (I've not checked in details). > Can these be stretched using mathfontUnicode.properties, as for U+00AF and > U+0332? They would then not be dependent on STIX fonts. Yes, I've prepared a patch for composite horizontal parentheses/bracket and I was thinking the same.

(In reply to comment #21) > > Note that there are already non-stretchy "infix" entries for these operators > > What do you mean? From bug 519126 comment 7, I think you want all the forms to > have similar properties. I disagree, we should really handle operators > differently according to its form. I agree there would be some situations where operators should be handled differently according to their form. When I tested, low line and tilde were not stretching in attachment 439767 [details]. I guessed that was because the infix forms were being used. (Removing the infix form from mathfont.properties made the tilde stretch.) > Here is what the spec says: > > http://www.w3.org/TR/MathML3/chapter3.html#presm.formdefval The operators in attachment 439767 [details] are the last arguments of an mover (not the last argument of an mrow), so that seems to say that the "infix" form should be used. > We do something more or less similar here: > > http://mxr.mozilla.org/mozilla-central/source/layout/mathml/nsMathMLmoFrame.cpp#367 Hmm. I don't see a check of whether the parent is an mrow. > > Do you know why the majority of accents in the dictionary have "postfix" form? > > Probably because, when they are used as the last element of > munder/mover/munderover, they are postfix. I didn't find anything in the spec to imply that. > Otherwise, the other rules of the > spec to determine the form (for example when the operator has only one form) > should probably help finding the right properties. Right, when there is only one form it should fallback to the properties of the postfix form, but that is not a reason to give the operator postfix form.

> When I tested, low line and tilde were not stretching in attachment 439767 [details]. > I guessed that was because the infix forms were being used. > (Removing the infix form from mathfont.properties made the tilde stretch.) OK, I see. I haven't got this problem, because I was testing with attachment 415005 [details] [diff] [review]. Without this patch, LookupOperators is not working as expected and returns only the first form found here: http://mxr.mozilla.org/mozilla-central/source/layout/mathml/nsMathMLmoFrame.cpp#199 > The operators in attachment 439767 [details] are the last arguments of an mover > (not the last argument of an mrow), so that seems to say that the "infix" form > should be used. Sorry, I was thinking there were an implied mrow in munder/mover/munderover. Apparently, our implementation is also only considering next and previous children in the first line I quote in comment 21. In that case, I can't explain the rationale for the choice of postfix forms. If we fix our code to follow what the spec says, there will be problem with low line, tilde and probably more operators with multiple forms. It's probably a good idea to raise that issue to the Math WG as well as why "check mark" is considered a mathematical operator.

Updated version: the only difference with attachment 439957 [details] [diff] [review] is that the infix forms of ~ and _ are now stretchy and horizontal. So all the stretchy accents will now stretch, even without attachment 415005 [details] [diff] [review]. The "check mark" can be ignored: the Math WG removed it from the operator dictionary.

Comment on attachment 441533 [details] [diff] [review] more variants and composite chars for stretchy accents [pushed] Would it make sense to also give the infix forms of ~ and _ the "accent" property?

(In reply to comment #26) > (From update of attachment 441533 [details] [diff] [review]) > Would it make sense to also give the infix forms of ~ and _ the "accent" > property? I've nothing against setting them as "accent" but in that case they will behave exactly as the postfix form and so be redundant. Ideally, I would prefer that we follow the WG dictionary and that we implement rules to determine the right form. Anyway, I don't believe the difference of rendering with/without accent is obvious. Hence for now, I think we can just take this patch as it is.

Comment on attachment 441533 [details] [diff] [review] more variants and composite chars for stretchy accents [pushed] http://hg.mozilla.org/mozilla-central/rev/ff34198fc669

(In reply to comment #27) It seems to me that there are some bugs in the WG dictionary and we have flexibility to not follow the dictionary precisely. However, if "accent" doesn't make much difference, then I guess there's no need to deviate. Closing this bug as a large number of operators are now covered. We can open other bugs if there are other operators needing support.