Bug 66282 - Replace <mfenced> elements by equivalent <mrow>+<mo> constructions
Replace <mfenced> elements by equivalent <mrow>+<mo> constructions
 Status: RESOLVED FIXED None LibreOffice Unclassified Formula Editor (show other bugs) 4.2.0.0.alpha0+ Master All All medium normal Frédéric Wang target:4.2.0 66416 Show dependency tree / graph

 Reported: 2013-06-27 21:36 UTC by Frédéric Wang 2013-07-03 07:04 UTC (History) 1 user (show) dr.khaled.hosny

Attachments
New output (8.94 KB, text/html)
2013-06-30 14:25 UTC, Frédéric Wang
Details

 Note You need to log in before you can comment on or make changes to this bug.
 Frédéric Wang 2013-06-27 21:36:18 UTC All "left ... ... right ..." commands should probably generate + rather than . Rationale: https://github.com/mathjax/MathJax/issues/359 Frédéric Wang 2013-06-27 21:55:31 UTC Mass changes to assign bugs to myself. Frédéric Wang 2013-06-30 14:25:21 UTC Created attachment 81745 [details] New output I've submitted a patch for review: https://gerrit.libreoffice.org/#/c/4632/ I attach the new output that you can view in Firefox. As a separate issue, I have to check the unicode characters used for open/close symbols. At least the angle brackets seem weird in Firefox (bad spacing, not stretchy). I suspect they use the old HTML4 ⟨ and ⟩ rather than the new HTML5 definition. Frédéric Wang 2013-06-30 20:35:35 UTC > As a separate issue, I have to check the unicode characters used for > open/close symbols. At least the angle brackets seem weird in Firefox (bad > spacing, not stretchy). I suspect they use the old HTML4 ⟨ and ⟩ > rather than the new HTML5 definition. I just verified and opened bug 66416. Khaled Hosny 2013-07-02 22:03:24 UTC I’m not sure I like this change, it looks to me like a workaround for a Gecko bug. The specification explicatively state that and its + “expanded” form should render the same, and looks more “semantically” correct to me (OK, it is presentation MathML after all, but preserving some semantics does not hurt). Frédéric Wang 2013-07-03 06:38:45 UTC The and + forms are strictly equivalent so one is not more semantically correct than the others (that's the point of having these fence="true" attributes on the expanded form). immediately gives that something is a fenced construction but you can guess that from the + form with slightly more effort... Anyway that does not help since tools must be able to understand the expanded form too. The reason for this change is more because is really poorly designed and duplicates the + features in an inconsistent and less expressive way. Basically, text is given in attributes rather than as text nodes in so you can no longer apply any stylistic, hyperlink or properties and all the tools that work on text nodes (search engines, copy and paste, Firefox DOM inspector) may just ignore the fences. For implementers, that means to maintain more code for and the implementation is inconsistent with the rest of the code base. The Gecko bug is minor here (it happens with very small height IIRC) but there have been / are many serious bugs in e.g. WebKit and MathJax implementations due to mfenced. Many people from the Math WG do not like that element and said it is only here to satisfy the demand of some groups of people. I think most MathML folks would love to drop it. As a comparison, introducing is like if someone would decide to write \mfenced[(][)]x in LaTeX instead of \left( x \right). That's actually even worse, because has the "separators" attribute. Even in LibreOffice code this leads to inconsistencies: is exported when there are exactly two operators and when both of them are stretchy but otherwise we fallback to + since that can not be encoded in . The MathML import code seems to handle both cases but I haven't tested if that works correctly and consistently. Frédéric Wang 2013-07-03 06:41:31 UTC Comment on attachment 81745 [details] New output This is now obsolete after bug 66416. Khaled Hosny 2013-07-03 06:57:30 UTC OK, the fence attribute seems good enough in preserving the left/right semantic. Commit Notification 2013-07-03 07:03:07 UTC Frederic Wang committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=c61f35275c613cf7ba6f1aa7bc8235340f9df8f7 fdo#66282 - MathML export: improve ExportBrace 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.