Description: FILE-OPEN ODT: Endnote doesn't have an indent between numbering and text Steps to Reproduce: 1. Open attachment 199593 [details] (bug 165564) Actual Results: No indent in the endnotes Expected Results: Indent in the endnotes Reproducible: Always User Profile Reset: No Additional Info: Found in Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 9bc5b89c149497a83117edfadc3fb0b96d2f9899 CPU threads: 4; OS: Windows 10 X86_64 (build 19045); UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL threaded and in Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: c92e4d1a944019dd5b14cdce3d85213d2a8d9e92 CPU threads: 4; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL threaded Fine in Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 7afd11f8e476884662c18db85445752cc030b2e2 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL threaded
Confirm with Version: 25.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 4727305dd2e6fa1e92408d9fd7fef70b8d1fb913 CPU threads: 4; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US Calc: threaded
This seems to have begun at the below commit in bibisect repository/OS linux-64-24.8. Adding Cc: to Mike Kaganski ; Could you possibly take a look at this one? Thanks 1b62c0d5cb7cc65caad7cf9f58586fa202dc45f9 is the first bad commit commit 1b62c0d5cb7cc65caad7cf9f58586fa202dc45f9 Author: Jenkins Build User <tdf@maggie.tdf> Date: Sun Jan 28 12:30:33 2024 +0100 source a93dbb720c981cf48284ccbabda6db67d4be930b 162654: Related: tdf#159382 Naming is hard: make initial monster shorter | https://gerrit.libreoffice.org/c/core/+/162654
What? The attachment 199593 [details] has the new flag (NoGapAfterNoteNumber) in its settings.xml. It was created using version 25.2.1.2. It is *intended* to have no spacing between the numbering and text. Indeed, that is only honored by version that knows that compatibility option. The original "Expected Results: Indent in the endnotes" is nonsense.
*** Bug 166420 has been marked as a duplicate of this bug. ***
Assuming bug 166420 to be a true duplicate: from scratch 1. New File 2. Type any text 3. Insert an endnote 4. Save as rtf/doc/docx 5. Close file 6. Open the saved file -> There is NoGapAfterNoteNumber Version: 25.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 5c7b3f5dc1f14081eed380999dc029a500784d55 CPU threads: 8; OS: macOS 14.7.4; UI render: Skia/Metal; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded
Please create a new bug.
(In reply to Telesto from comment #5) > 1. New File > 2. Type any text > 3. Insert an endnote > 4. Save as rtf/doc/docx > 5. Close file > 6. Open the saved file -> There is NoGapAfterNoteNumber Wait. But this is the correct behavior. Did you try to read bug 159382? "In Word, the footnote number is immediately followed by the text." The compatibility option *is* to make Writer behave as Word. When we open *any* Word format, we *must* behave as Word. What do you expect at all? Definitely: your expectation, that opening a Word file, you won't see a Word-compat option enabled - is INVALID. End of story.
Likely, this is an XY problem. And yes, this is invalid, but to clarify: 1. Opening the ODT from comment 0 works as it should. 2. Opening a DOC/RTF/DOCX from comment 5 has NoGapAfterNoteNumber enabled as it should. - but - 3. Opening a DOC/RTF/DOCX from comment 5 should have a tab in the endnote, as it has in Word, and in the word/endnotes.xml; but there isn't that tab on import. And THAT is because we used to export that tab when writing these file formats (because that's the only way way to create the spacing there); but we used to filter that tab out on import, because we didn't support the word-compatibility mode previously - and having *both* our spacing, *and* a tab, would mean double spacing. So now, when we support the compat mode, we need to stop filtering the tab out. As said, the XY problem (trying to "fix" an ODT, that shows as it should; or pointing to the enabled compat flag where it is enabled correctly, instead of explaining the *actual* problem of the spacing present before roundtrip, but lost after the roundtrip, *where Word has it*) - makes this bug inappropriate to track that actual problem. Please create a *proper* bug report.