Bug Hunting Session
Bug 95902 - Mathtype OLE formulas corrupted under Japanese Windows
Summary: Mathtype OLE formulas corrupted under Japanese Windows
Status: RESOLVED DUPLICATE of bug 99402
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
5.0.0.5 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisectRequest, regression
Depends on:
Blocks:
 
Reported: 2015-11-18 09:58 UTC by Massimo
Modified: 2016-08-21 16:33 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Writer file with Mathtype equation OLE embedded (11.41 KB, application/vnd.oasis.opendocument.text)
2015-11-18 09:58 UTC, Massimo
Details
Rendering under LO5 (corrupted) (112.57 KB, image/jpeg)
2015-11-18 09:59 UTC, Massimo
Details
Correct rendering under LO4 (112.68 KB, image/jpeg)
2015-11-18 10:00 UTC, Massimo
Details
LO 5.2 and 4.3.0.0.alpha0+ (54.65 KB, image/png)
2016-02-26 13:37 UTC, raal
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Massimo 2015-11-18 09:58:52 UTC
Created attachment 120616 [details]
Writer file with Mathtype equation OLE embedded

A similar bug was reported long ago (No. 39894) so this may be a regression. I have posted under that bug but nobody seems to take it seriously, although it is a very serious bug.
In the attachment there is an OLE object produced with Mathtype (http://www.dessci.com/en/products/mathtype/). If you use LO5 under English Windows, no problem. If you use LO5 under Japanese Windows (or English Windows in which the non-unicode applications use Japanese encode as default), you get a very weird corruption, where the parentheses are replaced by Chinese characters. If you use LO4 under Japanese Windows, no problem (see the screenshots). The same version of Mathtype is rendered differently under LO4 or LO5 if the OS is in Japanese (or at least the non-unicode applications use Japanese are default encoding), so the problem cannot be on the Mathtype side but must be on the LO side. The example is with Writer but the same problem occurs with Impress.
To replicate the bug you need a Japanese environment: it is thus necessary, I believe, that a Japanese developer has a look on this.
I cannot upgrade to LO5 because of this bug, I hope somebody will take it seriously.
Comment 1 Massimo 2015-11-18 09:59:41 UTC
Created attachment 120617 [details]
Rendering under LO5 (corrupted)

This is how the .odt file is rendered under LO5
Comment 2 Massimo 2015-11-18 10:00:06 UTC
Created attachment 120618 [details]
Correct rendering under LO4

This is how the .odt file is rendered under LO4
Comment 3 Massimo 2015-12-20 22:29:54 UTC
5.0.4.2 is out but the bug is still there. Nobody willing to take a look at this? For me, it's an absolute stopper, I cannot upgrade to LO5 until this bug is fixed.
Comment 4 Massimo 2016-02-14 11:28:38 UTC
LO 5.1 is out and this horrible bug is still there. This is a real stopper, I wonder if anybody among the developers has realised how serious it is?
Comment 5 Massimo 2016-02-26 12:59:07 UTC
Hello, anybody alive out there? I posted to the Japanese forum, to the English forum, submitted this bug report, I do not know what else I can do to draw the developers attention on this bug. I wonder if you have no LO5 users in Japan who are Mathtype customers. I have confirmed this bug with two Japanese students who had installed LO5 on their respective PCs to study some of my files and discovered they were unusable because the equations were all corrupted. In their case too, installing LO4 solved the problem. This must really have something to do with LO5 but nobody seems willing to investigate what's wrong. Frustrating, really really frustrating!
Comment 6 raal 2016-02-26 13:37:23 UTC
Created attachment 123010 [details]
LO 5.2 and  4.3.0.0.alpha0+

Confirm.
Version: 5.2.0.0.alpha0+
Build ID: aaca25d67eb5ea252730cdcf555ecc04ce04a5e6
CPU Threads: 4; OS Version: Linux 4.2; UI Render: default; 

I have not Japanese system, but bug seems to be appear.

Because this bug should be regression, you can do a bibisecting of the bug. See here: https://wiki.documentfoundation.org/QA/Bibisect
For help with bibisecting you can ask at QA IRC https://wiki.documentfoundation.org/QA/IRC or me via e-mail.
Comment 7 Massimo 2016-02-26 13:46:08 UTC
Yes, your screenshot is just like mine! Glad to see that somebody can confirm this bug, it's a first step forward.

I do not know anything of "bibisecting" but I am willing to learn. However, for "bibisecting" that I guess I have to install LO5. I am currently travelling abroad with only my laptop, I cannot install LO5 because in about one week I'm going to give five-days full lecture using many Impress files and a number of equations, which would be unreadable if I upgrade (I understand it is not possible to have two different versions of LO on the same PC, is it?). This means I'm obliged to wait until I go back and get my hands on another PC which I do not use for work and where I do have LO5 installed - that will be in about three weeks though...
Comment 8 Buovjaga 2016-02-28 16:38:39 UTC
(In reply to Massimo from comment #7)
> I do not know anything of "bibisecting" but I am willing to learn. However,
> for "bibisecting" that I guess I have to install LO5. I am currently

Nope, but you have to do something more complicated (all info is in the wiki article).

Btw. I don't see the problem. I see it like attachment 120618 [details]

Win 7 Pro 64-bit Version: 5.2.0.0.alpha0+
Build ID: 85fcf15ff41ceb95f46dee586ff7187551be4955
CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; 
TinderBox: Win-x86@39, Branch:master, Time: 2016-02-27_09:23:38
Locale: fi-FI (fi_FI)
Comment 9 Aron Budea 2016-06-18 23:18:32 UTC
Confirmed both in Windows and Linux, with same rendering as Massimo's (Windows) and raal's (Linux), I'm guessing it's caused by the same issue.

Earliest incorrect version tested: 5.0.0.5 (Windows), 5.0.5.2 (Linux)
Latest correct version tested: 4.4.0.3 (Windows&Linux)

In Windows 'Control Panel -> Region and Language -> Administrative -> Language for non-Unicode programs' has to be set to Japanese (requires restart) for bug to occur, as described in Description.
Comment 10 Aron Budea 2016-06-18 23:20:30 UTC
Addition: I tested with Windows 7 x64.
Comment 11 Aron Budea 2016-06-28 09:28:59 UTC
Note that similar-looking bug 100651 doesn't seem to be a regression.
Comment 12 Aron Budea 2016-08-21 16:33:50 UTC
Bibisecting in Linux revealed this to be caused by the same commit as bug 99402.

*** This bug has been marked as a duplicate of bug 99402 ***