The MathML REC says that the default values are "thickmathspace": http://www.w3.org/TR/MathML/chapter3.html#presm.mo.attrs In general, people use operators that are in our dictionary, so that's not a problem.
Here is an example in the MathML testsuite where we can see a problem: http://www.w3.org/Math/testsuite/build/main/Presentation/TokenElements/mo/mo6-full.xhtml
I'm guessing we only need to initialize lspace and rspace to the value of thickmathspace instead of 0 here: http://mxr.mozilla.org/mozilla-central/source/layout/mathml/nsMathMLmoFrame.cpp#386
(In reply to comment #1) > Here is an example in the MathML testsuite where we can see a problem: > > http://www.w3.org/Math/testsuite/build/main/Presentation/TokenElements/mo/ > mo6-full.xhtml the same converted into reftest: https://github.com/fred-wang/MathJax-test/blob/master/MathMLToDisplay/Presentation/TokenElements/mo/mo6.html https://github.com/fred-wang/MathJax-test/blob/master/MathMLToDisplay/Presentation/TokenElements/mo/mo6-ref.html
For both tests, we can see that the result is what we expected. But, with the tests proposed by Frédéric Wang, we can note there is a space not expected between f and (x). The applyfunction is treated like an mo that is not in the dictionary. If I comment the following condition: http://mxr.mozilla.org/mozilla-central/source/layout/mathml/nsMathMLmoFrame.cpp#182 the result is good. But there is a new problem, because the line is more below than the line of the reftest but I don't know why. To finish we can ask ourselves what we can do if the mo is not in the dictionary and at the beginning of the line. It would be better that the space shouldn't appear at the left of the mo.
Created attachment 630247 [details] [diff] [review] Patch V2
Created attachment 630248 [details] [diff] [review] Reftest
I assume that, if the scriptlevel and IS_ISOLATED tuning is appropriate for l/rspace from the dictionary, it would also be appropriate for default values. An implementation that changed the initialization of the lspace and rspace variables to the 5/18 default would be simpler and keep this tuning. Is there a reason why you wanted to avoid the tuning?
(In reply to Karl Tomlinson (:karlt) from comment #10) > An implementation that changed the initialization of the lspace and rspace > variables to the 5/18 default would be simpler and keep this tuning. > Is there a reason why you wanted to avoid the tuning? Yes, that's what I was wondering too. I don't have a strong reason, except trying to follow the MathML spec (but even thickmathspace = 5/18 is only a recommended value and I know that MathJax does not always follow the spacing recommended by the spec). I'll keep the tuning. (In general, I don't find this bug too important in practice, but it is a test in the MathML testsuite)
Comment on attachment 630247 [details] [diff] [review] Patch V2 (Comment 10)
Created attachment 635743 [details] [diff] [review] Patch V3 I forgot to update my patch sorry. The previous Try Server results in comment 12 was for this new version.
Pushed to mozilla-inbound: https://hg.mozilla.org/integration/mozilla-inbound/rev/08f12e27bf51 https://hg.mozilla.org/integration/mozilla-inbound/rev/ef4be3efbb41
Autoland Patchset: Patches: 630248, 635743 Branch: mozilla-central => try Patch 630248 could not be applied to mozilla-central. file layout/reftests/mathml/mo-lspace-rspace-ref.html already exists 1 out of 1 hunks FAILED -- saving rejects to file layout/reftests/mathml/mo-lspace-rspace-ref.html.rej file layout/reftests/mathml/mo-lspace-rspace.html already exists 1 out of 1 hunks FAILED -- saving rejects to file layout/reftests/mathml/mo-lspace-rspace.html.rej patch failed, unable to continue (try -v) patch failed, rejects left in working dir Patchset could not be applied and pushed.