Bug 64026 - Footnotes and Endnotes Get Strange Spacing (tabed) when Saving As .Doc or .Docx
Summary: Footnotes and Endnotes Get Strange Spacing (tabed) when Saving As .Doc or .Docx
Status: RESOLVED DUPLICATE of bug 71984
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
Depends on:
Blocks:
 
Reported: 2013-04-28 18:12 UTC by Rogier van Vlissingen
Modified: 2018-03-22 13:53 UTC (History)
5 users (show)

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


Attachments
Chapter from a book with 26 end notes. (241.00 KB, application/msword)
2013-04-28 18:12 UTC, Rogier van Vlissingen
Details
testfile in .odt (9.64 KB, application/vnd.oasis.opendocument.text)
2013-05-01 00:18 UTC, Rogier van Vlissingen
Details
test file in .doc (11.00 KB, application/msword)
2013-05-01 00:19 UTC, Rogier van Vlissingen
Details
testfile in .docx format (5.04 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2013-05-01 00:19 UTC, Rogier van Vlissingen
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rogier van Vlissingen 2013-04-28 18:12:10 UTC
Created attachment 78584 [details]
Chapter from a book with 26 end notes.

Problem description: 

Steps to reproduce:
1. develop document with footnotes or endnotes
2. save as .doc or .docx - everything will appear normal.
3. close and reopen and the end notes numbered above 9 (i.e. double digits) will be reformatted to 1 0. The references at the end will show 1 0 [tab] text of endnote.

Current behavior: deforming footnote references if they have double digits

Expected behavior: maintaining the formatting.

              
Operating System: Windows 7
Version: 4.0.0.3 release
Comment 1 Szuhánszky Tamás 2013-04-29 10:02:10 UTC
Hi!

With the file you attached, i could reproduce this behavior with Windows 7 64 bit.
Versions: 4.0.0.3 ; 4.0.2.2 and master 2013-04-29
Comment 2 Joel Madero 2013-04-30 21:59:17 UTC
Hm I can confirm behavior but is the same thing happening with odt? Also, does it happen with an easier test case (just a blank document with end notes)?
Comment 3 Rogier van Vlissingen 2013-04-30 22:23:52 UTC
Chapters ranged from 8-44 pages in length, and it was happening all the time. This chapter was merely the most extreme example.

I have had to give up using LibreOffice, for the first time since 13 years of using first OpenOffice, and now LibreOffice.
Comment 4 Joel Madero 2013-04-30 22:32:16 UTC
can you reproduce it on an empty document? Just insert -> end note 10 times? Does odt format work? Please answer all the questions that are asked :)
Comment 5 Rogier van Vlissingen 2013-04-30 23:48:34 UTC
(In reply to comment #4)
> can you reproduce it on an empty document? Just insert -> end note 10 times?
> Does odt format work? Please answer all the questions that are asked :)

In .odt it always worked, my problem is collaboration with M$drones, which seems unavoidable around here.

I set up a doc with 15 single letters, and a footnote for the first one, while also allowing the system to go with the defaults which is arabic numbering for the footnotes and roman numbers for the end notes. In this case the references stay in tact, however once you go to or .docx, an extra tab starts getting inserted.  

Then, when you switch to arabic numbering for the references, it starts to treat the references as single numbers, and insert blank space between the 1 and 1 of 11, as well as an extra tab after it.
Comment 6 Joel Madero 2013-04-30 23:50:19 UTC
Can you attach the original odt that is functional (not the book, a simple test case would be better)
Comment 7 Rogier van Vlissingen 2013-05-01 00:18:51 UTC
Created attachment 78672 [details]
testfile in .odt
Comment 8 Rogier van Vlissingen 2013-05-01 00:19:27 UTC
Created attachment 78673 [details]
test file in .doc
Comment 9 Rogier van Vlissingen 2013-05-01 00:19:57 UTC
Created attachment 78674 [details]
testfile in .docx format
Comment 10 Rogier van Vlissingen 2013-05-01 00:23:17 UTC
note that the choice to manually edit the references (switching from Roman numbering to Arabic numbering) seems to be one additional trigger - for the rest, the point remains that even as you save the file, nothing changes, but these spontaneous changes start happening after you reopen the file subsequent to conversion from .odt to .doc, or .docx
Comment 11 Rogier van Vlissingen 2013-05-01 04:45:44 UTC
In actual fact, the problem always was related to my having to convert from .odt to .doc for the sake of others.
Along the way it seemed that the irregularities became worse when I tried to get the end notes to be in Arabic, not Roman numbering, but that was an aggravating circumstance, not the cause. 
The trigger seemed to always be opening the file, not saving it. Everything would look normal, even with repeated saving, but as soon as you opened it in LO, the problems would reappear.
The only way to avoid it is to revert to MS Word, which is the first time in 13 years I've had to do that. But given that .doc format is mandatory, and it's the conversion that causes the problem, I ended up correcting the same problems with every new round of editing, and it became too much of a drag.
Comment 12 Joel Madero 2013-05-01 04:58:30 UTC
Doing further investigation tomorrow but I can confirm.
Comment 13 Rogier van Vlissingen 2013-05-01 05:11:20 UTC
I notice that you are limiting yourself to the problem with the funny tabs that appear out of nowhere.

The spontaneous change to the reference numbers, escpecially if they are manual, not automatic, is also a substantial part of the problem, and I've experienced it hundreds of times, and tried every imaginable workaround, but in the end I had to give up, and just limit myself to editing in .doc and in MSW. It was often costing me 15 minutes extra for each file to fix the conversion problems again and again and again.
Comment 14 Joel Madero 2013-05-01 05:24:17 UTC
I may open a second report, will look in depth tomorrow
Comment 15 Rogier van Vlissingen 2013-05-06 19:02:48 UTC
Maybe here is another argument for a second report.

In another chapter of the same book I had footnotes in Roman numbers i, ii, iii, iv... and endnotes in arabic numbers.

I converted it to .doc in LO, but when opened in MSW, the footnote references became arabic, and the end note references became roman, out of line with the rest of the book...

The ONLY way to make the conversion work without incident (sorry for some wry on OTJ humor here) was, believe it or not, to open the .odt in MSW, and convert it into .doc with MSW instead of with LO (sic!!!). After that the reference numbers were unchanged, and now I can work without incident in MSW.
Comment 16 Owen Genat (retired) 2013-10-02 08:29:35 UTC
Behaviour for this bug has improved under MacOS running LO v4.1.2.2 Build ID: 281b75f427729060b6446ddb3777b32f957a8fb and Word 2011 v14.3.7. Saving the example ODT (using LO) to DOC and DOCX and opening these files under the indicated versions of LO and Word version shows:

File   Open   Problems
----   ----   --------
DOC    Word   a. Endnotes positioned on wrong (first) page.
              b. First endnote has carriage return and tab between 
                 identifier and text.
              c. Footnote and endnotes all display[1] with a leading tab.
DOC    LO     Only (b) as above.
DOCX   Word   Only (a) and (c) as above.
DOCX   LO     d. Visible tab character prior to text of each footnote/endnote.

[1] Whether this is merely a display issue I am uncertain.

Setting status to NEW.
Comment 17 Timur 2014-10-29 13:01:41 UTC
While testing ODT saved as DOC from Bug 83005, I noticed that "Strange Spacing (tabed)" didn't appear with LO 4.4 from master of today.
Comment 18 Cor Nouws 2015-05-27 07:44:35 UTC
partial dup of https://bugs.documentfoundation.org/show_bug.cgi?id=71984 ?
Comment 19 Timur 2015-11-26 09:34:55 UTC
Testing with 5.0.3, attachment 78584 [details] has a fileopen problem with double digit endnotes but this may come from improper saving in previous versions. 
Looks like ODT attachment 78672 [details] is properly saved in DOC/X.
There's the issue with footnotes at the end of document but that's Bug 55427.
I suggest this be saved as WFM, unless there's a contrary argument.
Comment 20 Cromatino 2016-01-05 11:51:11 UTC
At present, this is still one of the most troublesome obstacles to using Libreoffice (or Openoffice...) Writer in professional situations. If you create documents with LO or OO, when you save/convert the files as .doc or .docx for people who work with Microsoft Office (example: publishers), you have to remove manually all the unwanted tabs at the beginning of every single footnote. This is not feasible when you have to handle long texts with dozens, hundreds or thousands of footnotes. So, in professional contexts, people are compelled to write documents with MS Word from start to finish because of this trivial defect. I suggest to change the "importance" to "major". I think this is a duplicate of Bug 71984 (not fixed yet).
Comment 21 Cor Nouws 2016-01-05 12:48:10 UTC
Marking as duplicate though the other is newer, but it's assigned and has a patch

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