https://bugs.documentfoundation.org/show_bug.cgi?id=79695
Regina Henschel <rb.hensc...@t-online.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rb.hensc...@t-online.de
--- Comment #7 from Regina Henschel <rb.hensc...@t-online.de> ---
A docx document is not helpful here, because it uses
"http://schemas.openxmlformats.org/officeDocument/2006/math";, which requires a
different filter.
This is about the MathML import filter. Our own MathML is not imported from the
pure MathML but from the embedded annotation, which contains the StarMath
string. The part, which can read pure MathML, is in a bad state. The internal
model is designed for StarMath and lacks many properties needed for MathML.
The attached document is far too large. The formulas might have different
problems and it would be good, to make a single issue for each problem, if not
already existing.
I have looked at the formula in the lower part of page 13. It is OLE-object
"18" in the navigator. I can identify some problems:
(1) StarMath does not allow an empty matrix cell. LibreOffice should insert a
small space or an empty string for StarMath in such cases.
(2) The brace for the case distinction is a <mml:mo>{</mml:mo>. It is imported
as lbrace. That is bad, because it does not preserve the default "stretchy"
attribute of this operator and prevents setting a closing "right none", which
is needed for StarMath, because it requires balanced brackets. LibreOffice
should use a "left lbrace" and insert a "right none", when the enclosed element
is closed and no bracket follows.
(3) The source uses <mml:mo>∣</mml:mo> to represent the lines of the abs
function, where the ∣ is the unicode symbol "DIVIDES". A literal translation
would result in StarMath operator "divides", which does not fit well in this
context.
StarMath itself uses the unicode symbol "VERTICAL LINE" for the lines of the
abs function and imports them as "left lline" and "right lline" in case the
annotation is missing.
I don't know a save algorithm to detect whether a true "divides" is intended or
not.
The operators have no mathematical meaning in Presentation MathML, so it is not
a direct fault, but it is at least bad style by Microsoft.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
