Bug 42768 - FILESAVE: when I make changes to a text in .doc format (or when transforming .odt into a .doc) and I reopen the file, footnotes and italics are not respected (or go mad, or disappear) (see comment 12 for actual description)
Summary: FILESAVE: when I make changes to a text in .doc format (or when transforming ...
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
3.3.4 release
Hardware: Other All
: medium normal
Assignee: Not Assigned
Whiteboard: BSA
Keywords: filter:doc
Depends on:
Blocks: Footnote-Endnote DOC
  Show dependency treegraph
Reported: 2011-11-09 22:51 UTC by Plotino
Modified: 2020-03-30 06:20 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:

.odt that shows the italics problem once converted in .doc (36.16 KB, application/vnd.oasis.opendocument.text)
2012-10-21 09:58 UTC, margheritarcangeli
pdf from the odt, which shows the right italics behaviour (71.24 KB, application/pdf)
2012-10-21 10:00 UTC, margheritarcangeli
pdf from the doc, which shows the italics problem (72.98 KB, application/pdf)
2012-10-21 10:01 UTC, margheritarcangeli
the converted file that shows the italics problem (16.00 KB, application/msword)
2012-10-21 10:04 UTC, margheritarcangeli
footnote_example.doc: example of a WORKING footnote (10.50 KB, application/msword)
2017-09-07 00:57 UTC, Justin L

Note You need to log in before you can comment on or make changes to this bug.
Description Plotino 2011-11-09 22:51:55 UTC
Problem description: I work with .odt files in libreoffice, and it's a great think. But I need to share my academic writings with other people, mostly Word users, so I convert my .odt files to .doc. And here's the problem.

When transforming the .odt files to .doc some footnotes duplicates or disappear. And some parts on the text in italic (for example, a title) changes to normal font. And some normal font is transformed to italic. 
That is very problematic, BUT is not the worse part!

Once the errors are done in the format transformation, I try to change them. So I fix all the mistakes (I delete some footnotes, remake others and place the italics where they should be) and SAVE my .doc file. But next time I open this same .doc file, all my corrections are gone...Bad think in deed. 

JUST one think: Because this doesn't always happens, I have the THEORY (just that, a theory) that this phenomena happens when I copy a paragraph from a .doc file (and I have a lot, because i sued to be a Word user) and paste it in a odt. AND THEN, when converting my .odt whit a paragraph or footnote borrowed from a .doc to a .doc, the problems appears (and can't be resolved making changes because, as I just said, the saving option malfunctions).

Complicated, isn't it? That's probably why we have this bug!!!!

Steps to reproduce:
1. ....
2. ....
3. ....

Current behavior:
.doc files are sometimes not saving my changes properly
Expected behavior:
I can modify and save and transform all the files without malfunctions.
Platform (if different from the browser): Natty, xubuntu, firefox
Browser: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20100101 Firefox/7.0.1
Comment 1 tester8 2012-01-06 17:07:11 UTC
Can you please upload .doc (pasting donor), .odt (pasting recipient) and .doc (saved from from .odt).
Comment 2 sasha.libreoffice 2012-04-19 05:34:13 UTC
Thanks for bugreport
Please, attach small odt file that demonstrates problem when saved to doc
Comment 3 dnh 2012-06-02 10:20:27 UTC
I can confirm this bug, random footnotes are deleted. Happens also for doc-files originally saved in Word.
Comment 4 sasha.libreoffice 2012-06-03 23:58:38 UTC

*** This bug has been marked as a duplicate of bug 46020 ***
Comment 5 margheritarcangeli 2012-10-19 20:32:09 UTC
This bug should be reopened, because it has been only partially solved. More precisely, 46020 concerns only the footnotes issue, but not the italic one.
Comment 6 margheritarcangeli 2012-10-19 21:05:50 UTC
As others LO users (see http://en.libreofficeforum.org/node/2801, and http://ask.libreoffice.org/question/4509/unwanted-italics/) I've experienced random unwanted italics in Writer. I didn't experience this problem with LO 3.4.4 under Linux/Ubuntu, but I did with LO and now also with LO and LO (always under Linux/Ubuntu).

I agree with Plotino, it is difficult to find out the steps to reproduce this bug. The random unwanted italics come when copy/pasting a paragraph from a .doc file, when sharing .doc files with non-LO users, or even when saving files in MS formats. Moreover, it does not help making changes to the file: all corrections are gone, once the file is reopened.

Apparently this bug is similar to other bugs, such as 46020, 50285 and 53856, but it is far from having been solved!
Comment 7 sasha.libreoffice 2012-10-20 09:18:15 UTC
Thanks for additional testing
I suspice that problem is with styles. May be wrong style taken from template.

Please, atach odt document that demonstrates this problem being saved to doc.
This is ultimate important for reporducing and fixing this problem.
Thanks in advance.
Comment 8 margheritarcangeli 2012-10-21 09:58:21 UTC
Created attachment 68868 [details]
.odt that shows the italics problem once converted in .doc
Comment 9 margheritarcangeli 2012-10-21 10:00:18 UTC
Created attachment 68869 [details]
pdf from the odt, which shows the right italics behaviour
Comment 10 margheritarcangeli 2012-10-21 10:01:16 UTC
Created attachment 68870 [details]
pdf from the doc, which shows the italics problem
Comment 11 margheritarcangeli 2012-10-21 10:04:05 UTC
Created attachment 68871 [details]
the converted file that shows the italics problem
Comment 12 margheritarcangeli 2012-10-21 10:05:51 UTC
Here is the .odt which demonstrates the italics problem once converted in .doc (not when converted in .docx, this is a good news!), as the pdfs show.

This should happen with LO, LO and LO (at least under Ubuntu 12.04) and not with LO 3.4.4 and OO versions before 3.3 (both under Ubuntu and MS).

Note that, even if the conversion has been done by non-affected versions of LO and OO, the .doc will show the random italics for affected versions. It seems that also the converse is true: the .doc converted by affected version of LO behaves normally for unaffected versions.

Finally, if an .odt is created from the affected .doc by affected versions of LO, it'll show the random italics.

Hope that all this might be of help!

Comment 13 sasha.libreoffice 2012-11-08 11:46:38 UTC
Reproduced in 3.6.3 on RFR 17 64bit
Steps to create test document:
0. Start Writer
1. Type or copy-paste several paragraphs of text into document
2. Assign character style "Emphasis" to all text (all will become italic)
3. Select all text and press Ctrl-I (all will become not italic)
4. Select some words in some paragraphs and press Ctrl-I (words are italic)
5. Save to doc format and File->Reload
Expected: document looking as before saving to doc
Actually: some paragraphs becomes italic from beginning of paragraph until and including word that indeed should be italic

It is FILESAVE problem, because file, saved by Writer looks in msWord exactly as in Writer after reopening

PS: may be we should create separate bugreport for this problem?
Comment 14 sasha.libreoffice 2012-11-08 11:51:31 UTC
in 3.4.2 on Windows XP problem not happens, therefore regression 
(also mentioned in Comment 12)
Comment 15 Björn Michaelsen 2014-10-10 23:51:31 UTC
original report against 3.3.4, so not a regression (but maybe a Heisenbug).
Comment 16 QA Administrators 2016-09-20 10:32:27 UTC Comment hidden (obsolete)
Comment 17 larrybradley 2017-07-30 12:46:29 UTC
When I purged 5.3 and installed 5.4 (Linux), then opened an existing large document that previously had more than a hundred footnotes, the footnote description/explanation lines existed, but the reference numbers that should have been in the body of the document were missing entirely. Of course, one of the results is that clicking on the footnote number in the footnote description / information line (see example below) takes you nowhere instead of taking you to the corresponding superscript number in the body of the document because the superscript number no longer exists. 

Example Footnote Line: 

105 Mr. Craigmile. N. A. C. S., Seventh Annual Proceedings, 1919, p. 614. 

(This is footnote No. 105. There is no longer a corresponding, linked 105 in the body of the document, i.e. clicking on the 105 in the footnote takes you nowhere because there is no longer a reference number in the body of the text that is linked to the footnote).

This is a complete and utter disaster for me, as I use LO for writing and editing manuscripts, many of which have more than one hundred footnotes each, not to mention that these manuscripts drafted in LO are converted to ePub and other formats for sale by download, something that has now been rendered impossible for me to do without many weeks or months of fixing every file that was drafted using LO.
Comment 18 Justin L 2017-09-07 00:57:34 UTC
Created attachment 136088 [details]
footnote_example.doc: example of a WORKING footnote

(In reply to larrybradley from comment #17)

Please provide an ultra-minimal example document that allows your problem to be reproduced.  footnote_example.doc works for me - I can click on both numbers and jump to the other side.  I can't reproduce your problem.
Comment 19 QA Administrators 2018-09-08 02:41:57 UTC Comment hidden (obsolete)
Comment 20 Sylvain 2019-01-19 17:06:41 UTC
I am seeing the loss of formatting for superscript characters and Heading style changes lost when doc is saved. On reopen, all formatting is lost for style changes and superscript formatting throughout document. These are 500+ page books, so this is very troublesome.
Comment 21 Justin L 2019-10-01 17:25:13 UTC
(In reply to Justin L from comment #18)
> Please provide an ultra-minimal example document that allows your problem to
> be reproduced.
Complex documents are basically useless for bug fixing.
Comment 22 QA Administrators 2020-03-30 02:32:25 UTC Comment hidden (obsolete)
Comment 23 Timur 2020-03-30 06:20:01 UTC
Not reading all, but italic issue from comment 12 is no longer repro. Closing.