Bug 67327 - Filesave DOC: maths formula is visually altered when reopened in LO (looks good in MSO)
Summary: Filesave DOC: maths formula is visually altered when reopened in LO (looks go...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Formula Editor (show other bugs)
Version:
(earliest affected)
3.6.7.2 release
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords: bibisected, bisected, filter:doc, regression
Depends on:
Blocks: DOC-Formula
  Show dependency treegraph
 
Reported: 2013-07-26 00:05 UTC by TDuell
Modified: 2022-11-14 03:32 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
odt file with maths demonstrates the problem (29.30 KB, application/vnd.oasis.opendocument.text)
2013-07-27 22:51 UTC, TDuell
Details
rendering from master sources/4.1 (12.26 KB, image/png)
2013-08-03 14:50 UTC, Julien Nabet
Details
Screenshot from .doc rendering (14.46 KB, image/png)
2013-08-03 23:13 UTC, TDuell
Details
rendering from master sources after doc conversion (12.37 KB, image/png)
2013-08-04 06:29 UTC, Julien Nabet
Details
ODT compared LO MSO (219.06 KB, image/png)
2020-11-13 07:37 UTC, Timur
Details

Note You need to log in before you can comment on or make changes to this bug.
Description TDuell 2013-07-26 00:05:20 UTC
Problem description: 
I'm using v3.6.7 (download from LO website) on Fedora 19 x86_64. I would normally  be using the package from fedora repo (4.1.0.1) but that crashes on FC19 as do other v4 available from LO site.
Steps to reproduce:
1. ....Write equation, save as .doc (Microsoft Word 97/2000/XP/2003)
2. ....Open saved .doc in LO
3. ....

Current behavior:
The equation is displayed larger, sometimes not displayed in any recognisable form
example...
the equation in original document
vec ar = vec a + vec %alpha X vec r + vec %omega X (vec %omega    X vec r ) 

The equation when the .doc is opened
 size 12{ { vec  {a}} ital "r= {" ital { size 8{a}}}" {X { {୲}} {X left ( {X { vec  {r}} {ω}} \(  \)  right )"} 
newline
{}

Expected behavior:
The equation to be displayed as it was in the original document, before saving as .doc
              
Operating System: Fedora
Version: 3.6.7.2 rc
Comment 1 Julien Nabet 2013-07-27 19:41:39 UTC Comment hidden (obsolete)
Comment 2 TDuell 2013-07-27 22:51:07 UTC Comment hidden (obsolete)
Comment 3 TDuell 2013-07-27 22:54:29 UTC
Comment on attachment 83107 [details]
odt file with maths demonstrates the problem

The attached odt file when saved as .doc and reloaded back into LO has the maths displayed incorrectly.
I am now using LO 4.1.0.1 from Fedora 19 repo, and it displays the same behaviour
Comment 4 Julien Nabet 2013-08-03 14:50:31 UTC
Created attachment 83584 [details]
rendering from master sources/4.1

On pc Debian x86-64 with master sources updated today and 4.1 sources updated yesterday, I had this rendering.
Comment 5 Julien Nabet 2013-08-03 14:54:35 UTC Comment hidden (obsolete)
Comment 6 TDuell 2013-08-03 23:13:35 UTC
Created attachment 83596 [details]
Screenshot from .doc rendering

This image is a screenshot of how a saved .doc looks when reloaded back into LO 4.1.
The maths looks good in saved LO .odt, but when saved as .doc and reloaded are rendered distorted.
I have reports that the maths are sometimes unreadable when my .doc are rendered in MS Word.
Comment 7 Julien Nabet 2013-08-04 06:29:15 UTC
Created attachment 83600 [details]
rendering from master sources after doc conversion

TDuell: I reproduced the same problem with 4.1 sources but there's a lot of improvement with master sources (see attachment).
Comment 8 Julien Nabet 2013-08-04 06:33:51 UTC
Frédéric: the last screenshot I attached shows you greatly improved the rendering of math equation after doc conversion. For this case there are still small tweaks to do but I think it could be interesting to cherry-pick the changes you made in 4.1 sources, what do you think?
Comment 9 TDuell 2013-08-04 06:46:00 UTC Comment hidden (obsolete)
Comment 10 Julien Nabet 2013-08-04 06:48:53 UTC Comment hidden (obsolete)
Comment 11 TDuell 2013-08-04 06:54:34 UTC Comment hidden (obsolete)
Comment 12 Julien Nabet 2013-08-04 06:58:43 UTC Comment hidden (obsolete)
Comment 13 Frédéric Wang 2013-08-04 08:06:17 UTC
(In reply to comment #8)
> Frédéric: the last screenshot I attached shows you greatly improved the
> rendering of math equation after doc conversion. For this case there are
> still small tweaks to do but I think it could be interesting to cherry-pick
> the changes you made in 4.1 sources, what do you think?

The main issue here seems to be the integration of formulas into the document: it seems that incorrect width/height attributes are saved when exported to .doc and then the formula is rendered distorsed when imported back. My work was really on the MathML export of the formula itself, so I'm not sure I fixed anything here. I only modified the XHTML export filter in bug 66645 to remove this kind of attributes and avoid confusing the rendering in browsers, but I'm don't know if this affects export to *.doc file.

I think someone mentioned a fix for baseline alignment of inline formulas on the mailing list, so perhaps the width/height have been fixed at the same time...
Comment 14 Julien Nabet 2013-08-04 10:55:20 UTC
Frédéric: you were right, I cherry-picked the patches I quoted but it didn't change anything.
Sorry for the noise.
Comment 15 Yury 2013-08-05 08:10:21 UTC Comment hidden (obsolete)
Comment 16 Julien Nabet 2013-08-06 10:20:34 UTC Comment hidden (obsolete)
Comment 17 TDuell 2013-12-08 01:26:28 UTC
This problem was solved in the Fedora LO package (4.1.3.2-6), but has re-appeared in the 4.1.3.2-8 Fedora package.
How can this be?
Comment 18 QA Administrators 2015-04-19 03:22:40 UTC Comment hidden (obsolete)
Comment 19 Buovjaga 2015-06-18 15:09:54 UTC
Still a problem.

Win 7 Pro 64-bit Version: 5.1.0.0.alpha1+
Build ID: 437210d58f32177ef1829d704f7f4d2f1bbfbfdd
TinderBox: Win-x86@39, Branch:master, Time: 2015-06-18_07:21:56
Locale: fi-FI (fi_FI)
Comment 20 QA Administrators 2016-09-20 10:14:39 UTC Comment hidden (obsolete)
Comment 21 Telesto 2016-12-21 18:33:51 UTC
Still reproducible with:
Version: 5.4.0.0.alpha0+
Build ID: 9cfb2f2f03b5ec086487fd483298466db0b09010
CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2016-12-20_23:58:02
Locale: nl-NL (nl_NL); Calc: CL
Comment 22 QA Administrators 2017-12-22 03:36:07 UTC Comment hidden (obsolete)
Comment 23 Timur 2019-11-05 13:40:39 UTC
Repro 6.4+
Comment 24 AJ Justin 2019-12-21 15:34:32 UTC Comment hidden (spam)
Comment 25 dante19031999 2020-11-12 22:32:02 UTC
I'm sorry for giving you bad news.
Doc is a Microsoft's file extention. That means you're rewriting in the file the formula as microsoft's formula code and after reimporting it. You wont never get the same results. In best case scenario you get something with the same meaning.
Comment 26 Timur 2020-11-13 07:37:16 UTC
Created attachment 167248 [details]
ODT compared LO MSO

I don't agree with WontFix because LO-saved DOC is reopened rather good with MSO. 
Meaning that DOC bug is not saving but that LO doesn't reopen it's saved DOC. 
And I guess it should. 

There's something unclear here. Comment 7 claims that attachment 83600 [details] is DOC from LO master and it looks good. But it doesn't unfortunately say which master and which commit. Should be found. Probably some change and revert in 4.2. 

I also add DOCX comparison. It's a different issue, not covered by this bug, but let me note that spacing is not correct. Should be searched for existing bug.
Comment 27 Timur 2020-11-13 08:54:08 UTC
There were 3 changes in 4.2, seen with Linux bibisect.

Bold bad to good:
commit 6156f462101e24f7277e9200ef0e4fe573c10ac5
Date:   Sat Sep 5 19:02:55 2015 +0800
    source-hash-150c9f8bbcffacc687a5603e2a589d2a3816dccb
    previous source-hash-32527be0677a8fa971ebbf39ca9cab9c5a3687fb
    
    commit 150c9f8bbcffacc687a5603e2a589d2a3816dccb
    Author:     Ricardo Montania <ricardo@linuxafundo.com.br>
    AuthorDate: Tue Jul 16 07:47:27 2013 -0300
    Commit:     Andras Timar <atimar@suse.com>
    CommitDate: Tue Jul 16 12:21:00 2013 +0000
        String.AppendAscii() cleanup in math


Good to garbled worse:
commit 64b4c036ddaf244dd5540d895a28b8d883bcba0b
Date:   Sat Sep 5 20:00:52 2015 +0800
    source-hash-924c2177416e61327b586be551428a1380f22133
    previous source-hash-47aaa1c0b1c1c589c80d9735deebbb784bfd7dd4
    
    commit 924c2177416e61327b586be551428a1380f22133
    Author:     Noel Grandin <noel@peralex.com>
    AuthorDate: Wed Aug 7 11:48:26 2013 +0200
    Commit:     Noel Grandin <noel@peralex.com>
    CommitDate: Mon Aug 12 11:56:47 2013 +0200
        convert vcl/source/filter/wmg/emfwr.hxx from String to OUString
            Change-Id: I5eb1c4dbccec0da5ebbef5fe15e03c368a32cfdd


Garbled worse to bad stretched:
commit f2f63cc02957456ce814e9d7f02e82b5de906bab
Date:   Sat Sep 5 22:05:17 2015 +0800
    source-hash-34e951bd7284d2e771c279e3adc3899d191fdad0
    previous source-hash-f58ee783eebf74108c1c1dd5f24e6abaa19c4f09
author	Stephan Bergmann <sbergman@redhat.com>	2013-10-09 21:01:15 +0200
More OUString::copy out-of-bounds fixes
Change-Id: I45762d167d04252e32155a7b23a3290688bccdf6


I consider this a regression. Not sure who to add.
Comment 28 Timur 2020-11-13 08:58:31 UTC
Hi Noel, please see this likely a regression. 
Seems that your commit ruined the formula save in DOC, which was later not adequately fixed by Stephan. 
I couldn't find those 3 commits in BZ, so no other testing documents.
Comment 29 QA Administrators 2022-11-14 03:32:17 UTC
Dear TDuell,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug