Bug 76296 - FILEOPEN: Open or import of MathML file does not write ~ or ` for the <mspace> element
Summary: FILEOPEN: Open or import of MathML file does not write ~ or ` for the <mspace...
Status: CLOSED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Formula Editor (show other bugs)
Version:
(earliest affected)
4.2.1.1 release
Hardware: Other Linux (All)
: medium normal
Assignee: Not Assigned
QA Contact:
URL:
Whiteboard: BSA target:5.3.0
Keywords:
Depends on:
Blocks:
 
Reported: 2014-03-17 23:22 UTC by Enchanter Thunderbird
Modified: 2017-01-13 18:38 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Test MathML file (1.39 KB, application/mathml+xml)
2014-03-17 23:22 UTC, Enchanter Thunderbird
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Enchanter Thunderbird 2014-03-17 23:22:15 UTC
Created attachment 95970 [details]
Test MathML file

Problem description: 
I got an upside down "?" in front of the equation when I open MathML file.

Steps to reproduce:
1. Just open the MathML

Current behavior:
an upside down "?" in front of the equation

Expected behavior:
Shouldn't have an upside down "?" in front of the equation
              
Operating System: Debian
Version: 4.2.1.1 release
Comment 1 Jorendc 2014-03-19 17:12:05 UTC
Well, that upside down question mark is due a wrongly formatted MathML code.

Your formula is:
matrix {# {italic "G"_italic "x" = left [ matrix {{-italic "1"} # italic "0" # italic "1" ## {-italic "2"} # italic "0" # italic "2" ## {-italic "1"} # italic "0" # italic "1"} right ]} # {"(1)"}}

If I just delete the first #, the question mark is gone:
matrix {{italic "G"_italic "x" = left [ matrix {{-italic "1"} # italic "0" # italic "1" ## {-italic "2"} # italic "0" # italic "2" ## {-italic "1"} # italic "0" # italic "1"} right ]} # {"(1)"}}

I'm not a MathML syntax expert, but I guess the formula was just incorrectly formatted?

Kind regards,
Joren
Comment 2 Enchanter Thunderbird 2014-03-20 22:44:17 UTC
I can't see anything wrong with the MathML file. It looks like the first empty element before '#' sign is caused by miss parsing the mspace element in the MathML file. The formula editor can ignore the first mspace or add '`' for spacing in the converted equation.
Comment 3 Marcos Souza 2014-04-05 15:15:10 UTC
(In reply to comment #2)
> I can't see anything wrong with the MathML file. It looks like the first
> empty element before '#' sign is caused by miss parsing the mspace element
> in the MathML file. The formula editor can ignore the first mspace or add
> '`' for spacing in the converted equation.

But, why you need the first # in the beginning of the formula? We could try to avoid this problem but, this seems to be a formula problem.

(I tried to open this file in Firefox, and it open it correctly)(In reply to comment #2)
> I can't see anything wrong with the MathML file. It looks like the first
> empty element before '#' sign is caused by miss parsing the mspace element
> in the MathML file. The formula editor can ignore the first mspace or add
> '`' for spacing in the converted equation.

It seems we need to improve our MathML import code... Maybe I can try to look at this in this week (I'm really busy, but, I can take a look....)
Comment 4 Regina Henschel 2015-12-18 18:02:21 UTC
The problem is, that the first cell in the table contains a <mspace> element. According to comment in SmXMLSpaceContext_Impl::StartElement() this should be translated to a ~. But that does not happen/get lost, so that in the actually inserted formula the first cell of the matrix is empty. If it was a ~, then it would be displayed without error.

So this issue has two parts:
 (short time) Why is no ~ in the cell?
 (long time) Extend StarMath with a true <mspace> element
Comment 5 Regina Henschel 2015-12-22 18:13:05 UTC
The ~ is not in the cell, because the method SmBlankNode::CreateTextFromNode() is not yet implemented.

The export of ~ and ` was corrected in bug 66075, but the import of <mspace> is not corrected. It adds only one ~ , independent of the attribute "width".

I change the subject to the underlying reason.
Comment 6 Regina Henschel 2015-12-24 13:51:11 UTC
I know what to do; but please be patient, I need some time, because I can only work on it in spare time.
Comment 7 Commit Notification 2016-11-15 00:29:36 UTC
Takeshi Abe committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=074f0ab1d76f16fe92493868e2f2de75e67792ef

tdf#76296 Import MathML's <mspace>

It will be available in 5.3.0.

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.
Comment 8 Xisco Faulí 2017-01-13 12:35:01 UTC
Hello,
Is this bug fixed?
If so, could you please close it as RESOLVED FIXED?
Comment 9 Regina Henschel 2017-01-13 18:38:42 UTC
It generates several gaps now to mimic the <mspace> element as far as possible with the current StarMath syntax. If there is the wish to extend StarMath to a real support of arbitrary spaces, that should be done as enhancement request in a new issue.

I have tested it in Version: 5.4.0.0.alpha0+
Build ID: 5adab0927483d039037b0f93894627e41a2c72f2
CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-01-09_23:34:00
Locale: de-DE (de_DE); Calc: group