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

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.

(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....)

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

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.

I know what to do; but please be patient, I need some time, because I can only work on it in spare time.

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.

Hello,
Is this bug fixed?
If so, could you please close it as RESOLVED FIXED?

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