Bug Hunting Session
Bug 105095 - Tab after autonumbering footnote vanishes in docx format - not in odt
Summary: Tab after autonumbering footnote vanishes in docx format - not in odt
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.2.0.4 release
Hardware: All All
: medium normal
Assignee: Miklos Vajna
URL:
Whiteboard: interoperability target:6.0.0 target:...
Keywords: bibisected, bisected, filter:docx, regression
: 92013 (view as bug list)
Depends on:
Blocks: Footnote-Endnote
  Show dependency treegraph
 
Reported: 2017-01-04 10:39 UTC by Hermann Rotermund
Modified: 2018-04-20 05:02 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
.odt file with footnote (24.29 KB, application/vnd.oasis.opendocument.text)
2017-01-05 09:57 UTC, Hermann Rotermund
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Hermann Rotermund 2017-01-04 10:39:02 UTC
Description:
I insert in Tools - Footnote/Endnote Settings a \t "After" Footnote number and define a tab position in the footnote paragraph style to get a space between number and footnote text. Works. But if the file is saved in .docx format the tab vanishes when I open it again. That is not the case if the file is saved in .odt format.

Steps to Reproduce:
1. Save a file with a footnote in docx format 
2. Close file
3. Open file again and look at footnote

Actual Results:  
Space gone

Expected Results:
Space kept as in .odt format version of file


Reproducible: Always

User Profile Reset: No

Additional Info:
[Information automatically included from LibreOffice]
Locale: en-US
Module: TextDocument
[Information guessed from browser]
OS: Mac OS X (All)
OS is 64bit: no
Builds ID: LibreOffice 5.2.3.3


User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_2) AppleWebKit/602.3.12 (KHTML, like Gecko) Version/10.0.2 Safari/602.3.12
Comment 1 Buovjaga 2017-01-05 09:41:34 UTC
Please attach a working .odt file so we can quickly test the docx problem.

Set to NEEDINFO.
Change back to UNCONFIRMED after you have provided the document.
Comment 2 Hermann Rotermund 2017-01-05 09:57:30 UTC
Created attachment 130166 [details]
.odt file with footnote

When I save it as .docx and open it again with LibreOffice, the space (tab) between footnote number and footnote text is gone
Comment 3 Buovjaga 2017-01-05 10:10:51 UTC
Reproduced with the .odt, but lucky for you, not in 3.6.7.2.

Arch Linux 64-bit, KDE Plasma 5
Version: 5.4.0.0.alpha0+
Build ID: 1a58cdf8af1aba52ce0a376666dd7d742234d7cf
CPU Threads: 8; OS Version: Linux 4.8; UI Render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on January 4th 2016

Arch Linux 64-bit
Version 3.6.7.2 (Build ID: e183d5b)
Comment 4 Aron Budea 2017-01-06 00:42:26 UTC
Tab is there in 4.1.0.4, missing in 4.2.0.4 / Windows 7. Adjusting version field.
Comment 5 Aron Budea 2017-01-18 06:06:17 UTC Comment hidden (bibisection)
Comment 6 Aron Budea 2017-01-18 06:07:59 UTC
Hm, the tab doesn't look fake here, but maybe Miklos can explain. The current behavior started with the commit referenced below, adding Cc: to Miklos Vajna, please take a look.

https://cgit.freedesktop.org/libreoffice/core/commit/?id=b38629ae210b204a6d24d6e9c5c62eaaf563d494
author		Miklos Vajna <vmiklos@collabora.co.uk>	2013-12-05 10:33:56 (GMT)
committer	Miklos Vajna <vmiklos@collabora.co.uk>	2013-12-05 10:50:42 (GMT)

"cp#1000017 DOCX/RTF import: avoid fake tab char in footnotes"
Comment 7 Hermann Rotermund 2017-01-18 09:03:20 UTC
To Miklos: The Tab – why "fake"? – is intentionally set in .odt, is correctly exported to .docx, correctly displayed in Word, but falsely omitted when re-imported to Writer. 
You seem to suppose that the Tab is unwanted ...
Comment 8 Commit Notification 2017-07-04 08:18:25 UTC
Miklos Vajna committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=abc440a691efb872afac385ce5ed28cd5db56c8c

tdf#105095 DOCX import: conditionally ignore leading tab in footnotes

It will be available in 6.0.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 9 Miklos Vajna 2017-07-04 08:22:16 UTC
See the above commit message, turns out there are two ways to have spacing between the footnote number and the footnote content; the original commit only considered the case when the tab was problematic. Now your case should have the tab, while the original use-case still has the tab removed. :-)
Comment 10 Commit Notification 2017-07-04 11:31:26 UTC
Miklos Vajna committed a patch related to this issue.
It has been pushed to "libreoffice-5-4":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=10019608fd49c9d96b7015f982f40b1c09bc8b14&h=libreoffice-5-4

tdf#105095 DOCX import: conditionally ignore leading tab in footnotes

It will be available in 5.4.0.2.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 11 Justin L 2018-03-28 06:41:51 UTC
Some comments about the fix.
1.) The purpose of the tab is to emulate LibreOffice behaviour in MSOffice. The tab only is useful if there is a hanging indent (that is larger than the footnote character). The value of the margin is actually irrelevant.
2.) It shouldn't be tied to the footnote style, but to whatever the actual paragraph property is - especially since the style might not even be applying to the footnote.
3.) Export doesn't use any of these qualifications either - it always adds a tab, regardless of margin or hanging indent. See bug 106062

#3 is the biggest problem - since any document authored in MSO is "broken" by this added tab in LO export.  No need to adjust the fix in this bug until #3 is resolved.
Comment 12 Justin L 2018-03-31 04:46:57 UTC
*** Bug 92013 has been marked as a duplicate of this bug. ***
Comment 13 Justin L 2018-04-20 05:02:50 UTC
(In reply to Justin L from comment #11)
> No need to adjust the fix in this bug until #3 is resolved.

The 3 patches for bug 106062 take care of all of these three concerns.