Download it now!
Bug 66282 - Replace <mfenced> elements by equivalent <mrow>+<mo> constructions
Summary: Replace <mfenced> elements by equivalent <mrow>+<mo> constructions
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Formula Editor (show other bugs)
Version:
(earliest affected)
4.2.0.0.alpha0+ Master
Hardware: All All
: medium normal
Assignee: Frédéric Wang
URL:
Whiteboard: target:4.2.0
Keywords:
Depends on:
Blocks: 66416
  Show dependency treegraph
 
Reported: 2013-06-27 21:36 UTC by Frédéric Wang
Modified: 2013-07-03 07:04 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


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.
Description Frédéric Wang 2013-06-27 21:36:18 UTC
All "left ... ... right ..." commands should probably generate <mrow>+<mo> rather than <mfenced>.

Rationale: https://github.com/mathjax/MathJax/issues/359
Comment 1 Frédéric Wang 2013-06-27 21:55:31 UTC
Mass changes to assign bugs to myself.
Comment 2 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 &lang; and &rang; rather than the new HTML5 definition.
Comment 3 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 &lang; and &rang;
> rather than the new HTML5 definition.

I just verified and opened bug 66416.
Comment 4 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 <mfenced> and its <mrow> + <mo> “expanded” form should render the same, and <mfenced> looks more “semantically” correct to me (OK, it is presentation MathML after all, but preserving some semantics does not hurt).
Comment 5 Frédéric Wang 2013-07-03 06:38:45 UTC
The <mfenced> and <mrow>+<mo> 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). <mfenced> immediately gives that something is a fenced construction but you can guess that from the <mrow>+<mo> 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 <mfenced> is really poorly designed and duplicates the <mrow>+<mo> features in an inconsistent and less expressive way. Basically, text is given in attributes rather than as text nodes in <mo> so you can no longer apply any stylistic, hyperlink or <mo> 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 <mfenced> 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 <mfenced> is like if someone would decide to write \mfenced[(][)]x in LaTeX instead of \left( x \right). That's actually even worse, because <mfenced> has the "separators" attribute.

Even in LibreOffice code this leads to inconsistencies: <mfenced> is exported when there are exactly two operators and when both of them are stretchy but otherwise we fallback to <mrow>+<mo> since that can not be encoded in <mfenced>. The MathML import code seems to handle both cases but I haven't tested if that works correctly and consistently.
Comment 6 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.
Comment 7 Khaled Hosny 2013-07-03 06:57:30 UTC
OK, the fence attribute seems good enough in preserving the left/right semantic.
Comment 8 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.