Created attachment 117643 [details]
Screenshot of the problem in LO 5.1alpha. Note the extra tab character.
1, Add a footnote to a text document in LO 5.1 alpha.
2, Write two paragraphs into the footnote.
3, Save as DOCX or DOC or RTF. You get a warning that the document contains formatting that is not supported and may be lost.
4, Close the document, reopen with LO 5.1 alpha.
5, Now there is a tab character added after the first paragraph sign that was not there at saving. This happens all the same in the DOCX, DOC, RTF case.
There should be no tab character added.
If I save to ODT format, the formatting is preserved correctly: no extra tab.
Created attachment 117644 [details]
Correct document in ODT format
Created attachment 117645 [details]
Export of the ODT document to DOCX
Created attachment 117646 [details]
Export of the ODT document to DOC
Created attachment 117647 [details]
Export of the ODT document to RTF
Seems like this issue was earlier detected in bug 39205.
I can confirm with Version: 18.104.22.168.alpha1+ (x64)
Build ID: e92a8b92072284fd7c37d7bb3e1e8fe72a185f35
TinderBox: Win-x86_64@62-TDF, Branch:MASTER, Time: 2015-07-22_21:46:26
** Please read this message in its entirety before responding **
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 on a currently supported version of LibreOffice
(5.1.5 or 5.2.1 https://www.libreoffice.org/download/
If the bug is present, please leave a comment that includes the version of LibreOffice and
your operating system, and any changes you see in the bug behavior
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave
a short comment that includes your version of LibreOffice and Operating System
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)
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: http://webchat.freenode.net/?channels=libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!
Still the same in LO 5.2.1 on Ubuntu. An extra tab is added to the saved docx file.
*** Bug 112886 has been marked as a duplicate of this bug. ***
Note that with .docx files (I can't reproduce with .doc) a tab is added in each single-paragraph footnote at the very beginning. So no need to make two paragraphs in the footnotes: each and every one will get that tab character regardless. At least with 22.214.171.124 on Ubuntu 16.04.
Is there any workaround for this? It's really annoying when you are editing and adding comments to a colleague's paper and they wonder why the hell you added a bunch of tabs to their work.
According to bibisect-43all, this tabstop has been added as far back as I can go (LO3.5). Over time, there have been extra CRs added or deleted, but the tab on the second paragraph has always been there.
The most recent change was to fix a removed CR in LO 5.1 by Miklos Vajna on 2015-07-06 09:57:11 (GMT) commit 519b34300f73b1e08f6194d6ba49d4fc010cf186
tdf#90611 DOCX import: fix missing paragraph style on footnotes
The best inspiration should come from this patch from LO 4.3. Before that the first paragraph also start with a tab. See commit b38629ae210b204a6d24d6e9c5c62eaaf563d494 from Miklos Vajna on Thu Dec 5 11:50:42 2013 +0100
cp#1000017 DOCX/RTF import: avoid fake tab char in footnotes
Word wants this, so it's added by the exporter to the document, but on
import we should ignore it.
The tab is added in wrtw8nds.cxx ::OutputTextNode - look for 0x09.
Marking as an easy hack since I've given a lot of pointers. This will require a lot of testing - to ensure that no regressions happen. Many changes have occurred to footnotes - perhaps the tab is no longer necessary at all, but certainly it should be removed for extra paragraphs.
Especially take note of related bug 112886, which is not really a duplicate and presents some non-standard issues.
My target is that this should be fixed for LO 6.1.
Created attachment 140627 [details]
tdf93121_tabBeforeFootnoteWhenResaved.docx: created in Word 2013
It looks good when opened in LO, but after a round-trip, tabs are inserted in all three footnote paragraphs. Word also sees these tabs in the RT file. Since this bug report starts with an ODT, it indicates an export bug, not import bug.
proposed fix: https://gerrit.libreoffice.org/51628
Created attachment 140766 [details]
footnote-twoparagraphs.odt: LO authored documents with margin need a tab
LibreOffice seems to automatically start the footnote paragraph at the paragraph margin, and only the footnote character follows the first line margin. Word doesn't do such a thing, so that is why a tab is inserted.
Created attachment 140767 [details]
tdf93131_footnoteHangingIndent.docx: word2003 highlighting fundamental difference
LO's footnote implementation is fundamentally different from Word in regard to where the footnote paragraph starts.
Created attachment 140768 [details]
tdf93131_footnoteHangingIndent.pdf: How it looks in Word 2003
In MS Word, the footnote paragraph starts one space after the footnote character, not at the paragraph margin.
I noticed the missing # in the fixing commit's subject line, but since it still linked the this bug from gerrit, I didn't bother to fix that. Now I know it has implications on automatic comments for bugzilla.
Not planning to backport - too much chance for unanticipated regressions in this area of "emulating behaviour".