Bug 45284 - formulas in writer file exported to word are sized incorrectly
Summary: formulas in writer file exported to word are sized incorrectly
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Formula Editor (show other bugs)
(earliest affected)
3.5.0 RC2
Hardware: Other All
: medium normal
Assignee: Not Assigned
Keywords: filter:doc
: 40187 (view as bug list)
Depends on:
Blocks: DOC-Formula
  Show dependency treegraph
Reported: 2012-01-26 12:41 UTC by Yury
Modified: 2021-01-09 03:50 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:
Regression By:

remove appending of the hard-coded font sizes (made against git checkout) (1.09 KB, text/plain)
2012-01-26 12:41 UTC, Yury
10pt equivalent of ooo's "{a123} wideslash {b456}" made in word (15.50 KB, application/msword)
2012-03-03 03:08 UTC, Yury
14pt equivalent of "{a123} wideslash {b456}" made in word (15.50 KB, application/msword)
2012-03-03 03:10 UTC, Yury
10pt imported with 3.5.1rc1 (33.59 KB, image/png)
2012-03-03 03:15 UTC, Yury
14pt imported with 3.5.1rc1 (34.30 KB, image/png)
2012-03-03 03:16 UTC, Yury
10pt imported with patched 3.5.0 (40.12 KB, image/png)
2012-03-03 03:16 UTC, Yury
14pt imported with patched 3.5.0 (39.27 KB, image/png)
2012-03-03 03:17 UTC, Yury
LOdev patch blocking those 'size 12' and 'size 8' elements (1.46 KB, patch)
2015-04-20 08:31 UTC, Yury

Note You need to log in before you can comment on or make changes to this bug.
Description Yury 2012-01-26 12:41:06 UTC
Created attachment 56202 [details]
remove appending of the hard-coded font sizes (made against git checkout)

This is about formulas in writer file which is being exported (saved as) microsoft word .doc file. 

The current conversion routines in starmath/ subdir append hard-coded font sizes ("size 12" to normal content, "size 8" to super- and subscripts etc.), regardless of what is set in LibreOffice formula editor's settings. That is, of course, completely wrong approach. This way formulas are, in fact, corrupted. There are many tickets for this issue filed in OOO bugzilla, by the way.

One way of correcting this is proposed in a patch attached, pending the implementation of "completely correct" way of exporting font sizes in formulas to .doc (in ole streams attributes). This patch just removes the code which adds "size %d {" and corresponding "}".

"Works for me", as now I'm able to export many-formulas document to word's .doc and not have to *edit* each and every of those, if something other than "size 12" is required (I still have to double-click each and every of those to correct the previews, but that's another problem, albeit related).
Comment 1 sasha.libreoffice 2012-02-17 07:55:23 UTC Comment hidden (obsolete)
Comment 2 sasha.libreoffice 2012-02-29 01:23:25 UTC Comment hidden (obsolete)
Comment 3 Michael Stahl (allotropia) 2012-02-29 02:13:01 UTC
sounds plausible, but i know ~nothing about WW8;
Caolan, Cedric, Lubos: please take a look at the patch here
Comment 4 Caolán McNamara 2012-02-29 04:06:51 UTC
seeing as this is a patch to the import, I guess the problem is a round trip from .doc back to .doc again ?

Can you attach a demo document which shows the problem that this fixes. Its been a very long time since I played with the MathType format.
Comment 5 Ivan Timofeev (retired) 2012-02-29 07:16:37 UTC
Heh, since I am in the CC list... :)
The patch looks a bit weird to me: it removes the support of the SIZE record of the MTEF. However, MTEF is the format I am not familiar with, I have just downloaded the specification and looking into it right now. :)
Comment 6 Yury 2012-02-29 10:38:29 UTC
I'll attach a prepared and re-tested example tomorrow. 

And, like I said before, this patch is not a real solution, but a kludge, really. 

As I don't understand the starmath module too well myself, I've just removed ("hacked off") a provision for inserting the "size" tag, which is abused by export to Word Eq. editor AND import from Word Eq. editor routines. Personally, I can live without "size" tag (I'd rather have a global font size(s) changing control/dialog), but the effective corruption of formulas by insertion of "size 12", "size 8" is quite a PITA.
Comment 7 Yury 2012-03-03 03:08:47 UTC
Created attachment 57967 [details]
10pt equivalent of ooo's "{a123} wideslash {b456}" made in word
Comment 8 Yury 2012-03-03 03:10:58 UTC
Created attachment 57968 [details]
14pt equivalent of "{a123} wideslash {b456}" made in word
Comment 9 Yury 2012-03-03 03:15:51 UTC
Created attachment 57969 [details]
10pt imported with 3.5.1rc1
Comment 10 Yury 2012-03-03 03:16:17 UTC
Created attachment 57970 [details]
14pt imported with 3.5.1rc1
Comment 11 Yury 2012-03-03 03:16:55 UTC
Created attachment 57971 [details]
10pt imported with patched 3.5.0
Comment 12 Yury 2012-03-03 03:17:21 UTC
Created attachment 57972 [details]
14pt imported with patched 3.5.0
Comment 13 Yury 2012-03-03 03:36:01 UTC
Okay, here come the examples. Two files contain an equivalent of "{a123} wideslash {b456}" prepared in Word 2003 eqaution editor. One was composed with font size set to 10pt, another — to 14 pt. 

Please note that the overall formula's font size in examples isn't actually included into mathtype equation elements, but is put into a position preceding the equation proper. This is deduced from the binary comparison results.

Now, the import screens show where things go wrong in the mainstream LibO/OOO:

1) The formula's font size (10pt or 14pt in this case) is lost. The actual formula font size setting is in all cases 11pt (as set as default in local installation; dialog not shown), and so differs with what was actually set in Word file. This is, however, bearable.

2) What's worse, formulas get sprayed with «size 12» and «size 8» (these are arbitrary sizes taken from the array in the starmath/source/mathtype.cxx, in function MathType::Init()), which is completely unacceptable. Just imagine clearing those out in 100 formulas or so.

P.S. As a side question, I notice that, e.g., CmathOOO extension is capable of composing the formula «on the run» and inserting it with font size and face taken from paragraph style. How difficult would it be to implement: 1) *optional* setting of font size and face in imported formulas to whatever was set in imported file (say, Times New Roman and 10pt); 2) batch changing of the font faces and sizes of all formulas in LibO/OOO document; optionally, do it like it's done in KDE fonts dialog (adjust face only, or size only, etc.)?
Comment 14 Cédric Bosdonnat 2014-01-20 09:00:31 UTC
Restricted my LibreOffice hacking area
Comment 15 Yury 2015-04-20 08:30:04 UTC
Summing up, this issue is caused by the DOC to ODT importing routines doing two things wrong:

1bad) Formulas' font sizes' settings in DOC are ignored and substituted by hard-coded sizes coming, I believe, from the array MathType::aSizeTable[7] (starmath/source/mathtype.hxx). This produces the (unasked for) 'size 12' and 'size 8' on bodytext and indexes formulas' elements.

** I'm attaching the patch for LOdev which blocks (hacks off, really) that (spurious) size setting on import. Ugly, but "worksforme", saves my time.

2bad) Formulas' rendered images' frames are put too high w/r to the baseline of the paragraph formula is in. This necessitates re-rendering (double-clicking+closing) all formulas in the ODT (grand PITA!!)

Not *immediately* relevant to this issue is there are errors in the importing code, which converts the syntax of the MathType included in MS Word to the syntax of eqn included in LO.
Comment 16 Yury 2015-04-20 08:31:10 UTC
Created attachment 114955 [details]
LOdev patch blocking those 'size 12' and 'size 8' elements
Comment 17 Roeland 2015-09-20 08:39:46 UTC Comment hidden (obsolete)
Comment 18 Yury 2015-09-20 11:07:23 UTC
(In reply to Roeland from comment #17)
> Hi Yury, so if I understand correctly this isn't a final solution but a
> temporary workaround? Is there a possibility to resolve this issue, or is it
> too difficult to find an answer?

This solution is just a workaround, which I use in my local build, deployed on my machines. Frankly, this is quite a fair solution, see also https://bugs.documentfoundation.org/show_bug.cgi?id=90406, but it doesn't seem it can make it into the mainstream.
Comment 19 Buovjaga 2016-05-01 17:10:27 UTC Comment hidden (obsolete)
Comment 20 Yury 2016-05-01 17:37:27 UTC
(In reply to Buovjaga from comment #19)
> Yury: is this the same as bug 40187 ?

Yes, the very same. The source of .DOC, be it Word or LO, affects nothing.
Comment 21 Buovjaga 2016-05-01 17:51:20 UTC
*** Bug 40187 has been marked as a duplicate of this bug. ***
Comment 22 QA Administrators 2017-05-22 13:38:48 UTC Comment hidden (obsolete)
Comment 23 Roeland 2019-01-08 20:02:24 UTC
Yury, are you still woking on this? Is there no way to push the workaround as a temporary solution? or is this not possible?
Comment 24 Yury 2019-01-09 06:53:16 UTC
To be precise, I'm still _using_ this, locally building from source with that patch.
Comment 25 QA Administrators 2021-01-09 03:50:48 UTC
Dear Yury,

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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa

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

Warm Regards,
QA Team