Created attachment 78584 [details]
Chapter from a book with 26 end notes.
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: 220.127.116.11 release
With the file you attached, i could reproduce this behavior with Windows 7 64 bit.
Versions: 18.104.22.168 ; 22.214.171.124 and master 2013-04-29
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)?
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.
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 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.
Can you attach the original odt that is functional (not the book, a simple test case would be better)
Created attachment 78672 [details]
testfile in .odt
Created attachment 78673 [details]
test file in .doc
Created attachment 78674 [details]
testfile in .docx format
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
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.
Doing further investigation tomorrow but I can confirm.
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.
I may open a second report, will look in depth tomorrow
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.
Behaviour for this bug has improved under MacOS running LO v126.96.36.199 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 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.
 Whether this is merely a display issue I am uncertain.
Setting status to NEW.
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.
partial dup of https://bugs.documentfoundation.org/show_bug.cgi?id=71984 ?
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.
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).
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 ***