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
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.
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
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)
Tab is there in 4.1.0.4, missing in 4.2.0.4 / Windows 7. Adjusting version field.
95bfb76aa0b9fae094d3111dbfc58c29e63975df is the first bad commit commit 95bfb76aa0b9fae094d3111dbfc58c29e63975df Author: Matthew Francis <mjay.francis@gmail.com> Date: Thu May 28 17:37:23 2015 +0800 source-hash-b38629ae210b204a6d24d6e9c5c62eaaf563d494 commit b38629ae210b204a6d24d6e9c5c62eaaf563d494 Author: Miklos Vajna <vmiklos@collabora.co.uk> AuthorDate: Thu Dec 5 11:33:56 2013 +0100 Commit: Miklos Vajna <vmiklos@collabora.co.uk> CommitDate: 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. Change-Id: Idcb669ba624bf462a50a85eb4aacf397afb6efe6 # bad: [74b89c3193673ba9897dc4a4541500ef6e8d9bf7] source-hash-8f97326bdd3f42fc82aa5e1989fd03b0af1daf64 # good: [9c392cfdfe6e9a9bce98555ea989283a957aa3ad] source-hash-fc8f44e82de4ebdd50ac5fbb9207cd1a59a927e3 git bisect start 'latest' 'oldest' # bad: [e289d9d328719fd70e9a2680fd0e4f586a97b3be] source-hash-3c0a7cf4f67720f2cca2c4eb543f838d5b644e7f git bisect bad e289d9d328719fd70e9a2680fd0e4f586a97b3be # bad: [0327d0bc45d60df0d1c8ac2470cf252b6bb8f780] source-hash-38fed70782ae6ac6b0282897c7abc6fa33a6de9e git bisect bad 0327d0bc45d60df0d1c8ac2470cf252b6bb8f780 # bad: [130c0f90cdc74b7300c74ee7d49c459ea8b8c4f4] source-hash-4a969ac35174520f1ffeb4f919f5d7bb6d99a628 git bisect bad 130c0f90cdc74b7300c74ee7d49c459ea8b8c4f4 # bad: [a4ca1d9431eedeb3ce6b22b96cfabc5ccc3cb857] source-hash-c85f1ed54f64bb7c7d309ec87df9ce8027a4a108 git bisect bad a4ca1d9431eedeb3ce6b22b96cfabc5ccc3cb857 # good: [b41194f886e84e8427e7c389e7cd8e66b888372a] source-hash-0379f8b6393e99667584a2964bedf82e4306c2fa git bisect good b41194f886e84e8427e7c389e7cd8e66b888372a # good: [63e9dbb3a47ee35637f851efbdfb936aa31e5216] source-hash-ef1b4c3a5ea6e70a3831d29133ca291aee89f177 git bisect good 63e9dbb3a47ee35637f851efbdfb936aa31e5216 # bad: [1bb6fa11d9e3cf955f59730f34094c726a9d931e] source-hash-b0a16835ab401e8e973b2747aae4667129c13b4f git bisect bad 1bb6fa11d9e3cf955f59730f34094c726a9d931e # good: [405345a6365b10be18299c3eacd1ea8849d16cb1] source-hash-eb45c69b64ef19a33e4c04c6eba3733f18f8b5fc git bisect good 405345a6365b10be18299c3eacd1ea8849d16cb1 # bad: [3b48147989d130c819a4310d47d4149e4a0cddd9] source-hash-b415ec8cad8224c58d149626ddc3365575aa855e git bisect bad 3b48147989d130c819a4310d47d4149e4a0cddd9 # bad: [874fcbc111d4a282b5997e2ecbe49e09db0ee2f7] source-hash-059cc67245a4f0a62589a0c877aea85e8859c435 git bisect bad 874fcbc111d4a282b5997e2ecbe49e09db0ee2f7 # good: [97411235470b032554fe24333bddc82202fade87] source-hash-8735d039b00ba4f4ade0d0373b8c6341a9a4d763 git bisect good 97411235470b032554fe24333bddc82202fade87 # good: [230f1c77edc41604522c18a63216201afd74b916] source-hash-4eaa08f1d4e110dd3c3f464eaf9e7c526b7c28f7 git bisect good 230f1c77edc41604522c18a63216201afd74b916 # good: [76e5a40ae20b4e33a0591b235bf51dee27d4f8dc] source-hash-215f87fb53164a5fc9af13acdad7fdada2117b60 git bisect good 76e5a40ae20b4e33a0591b235bf51dee27d4f8dc # bad: [95bfb76aa0b9fae094d3111dbfc58c29e63975df] source-hash-b38629ae210b204a6d24d6e9c5c62eaaf563d494 git bisect bad 95bfb76aa0b9fae094d3111dbfc58c29e63975df # first bad commit: [95bfb76aa0b9fae094d3111dbfc58c29e63975df] source-hash-b38629ae210b204a6d24d6e9c5c62eaaf563d494
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"
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 ...
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.
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. :-)
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.
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.
*** Bug 92013 has been marked as a duplicate of this bug. ***
(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.