Summary: | Improve grouping of binary operators | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | Frédéric Wang <fred.wang> |
Component: | Formula Editor | Assignee: | Frédéric Wang <fred.wang> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | rb.henschel |
Priority: | medium | ||
Version: | 4.2.0.0.alpha0+ Master | ||
Hardware: | All | ||
OS: | All | ||
See Also: | https://bugs.freedesktop.org/show_bug.cgi?id=65765 | ||
Whiteboard: | target:4.2.0 | ||
Crash report or crash signature: | Regression By: |
Description
Frédéric Wang
2013-06-23 13:57:15 UTC
Makes sense to me. And following the fact it looks like you are an expert on this domain -> NEW right away. Kind regards, Joren It turns out that the first problem is a bit more complicated than I thought. At the moment the grammar is basically An Expression is a list of Relations A Relation is a list of Sums separated by relation operators A Sum is a list of Product separated by sum-like operators Product is a list of Power separated by product-like operators Power is a base and various sub/supscript Terms attached with _, ^ etc Term are basic tokens (identifier, numbers...) and various other commands. First you want to consider implicit product. So for example one would also like 1 + 3 x^2 to be interpreted as 1 + {3 x^2} rather than {1 + 3} x^2 (as it is currently the case). So a natural method could be to redefine Sum as a list of ImplicitProducts as a list separated by sum-like operators ImplicitProducts as a list of Product I tried that but then Binom is defined as a pair of two Sum, so for example "binom a b" will be interpreted as "binom {a b}" with the new syntax. I tried changing Binom to a pair of two Product make, but other test failures happened. Probably, allowing implicit products will lead to an ambiguous grammar (if it is not already) and a more clever parser would be necessary... I've submitted a patch for the second problem: https://gerrit.libreoffice.org/#/c/4520 I've opened bug 66200 for the first problem. I gave up fixing it in the short term as I suspect it would require too much work for only small benefits (the bad parsing of product does not really seem to affect the rendering or navigation in Math but is visible in the MathML output). Marking these bugs assigned since I've already taken them. Frederic Wang committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=4f294a90877d2f91bb88c7d6cd5b74e8e546a025 fdo#66081 - reduce the number of nested <mrow>'s in MathML The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback. I guess this can be closed since the second problem should be fixed and I've opened bug 66200 for the first problem. Testcase try to export "a*b*c + d*e*f + g*h*i = a*b*c + d*e*f + g*h*i = a*b*c + d*e*f + g*h*i" to MathML .mml to see the difference. (In reply to comment #7) > I guess this can be closed since the second problem should be fixed and I've > opened bug 66200 for the first problem. Okay, wasn't sure about this one :). -> RESOLVED FIXED _o_ thank you :) |