See attachment 132787 [details]. In 5.3.1 an additional space after the chapter number in a Table of Content was introduced. You can test it with attachment 132787 [details] of bug 44282. Illustration and table indexes are not affected. 5.3.0 wasn't affected. 5.3.2 and later versions are also affected. Steps to reproduce: 1. Open the mentioned Writer file. 2. Update the table of indexes. Actual result: 2.1 Heading level 2 ................. 2 -1 Expected result: 2.1 Heading level 2 ................. 2-1
I confirm it with Version: 6.0.0.1 (x64) Build ID: d2bec56d7865f05a1003dc88449f2b0fdd85309a CPU threads: 4; OS: Windows 10.0; UI render: GL; Locale: de-DE (de_DE); Calc: CL The difference between TOC and illustration and table index is, that the entry is different: TOC: Chapter No. Table index: Chapter Info
(In reply to Thomas Lendo from comment #0) Have you tested it with a different locale? The problem does not appear in my LibreOffice.
Weird. I tested it with English and German locale and a new profile. No difference. Version: 6.1.0.0.alpha0+ Build ID: 38f5e768b0f858f8f990a8f297396821c75d45dc CPU threads: 4; OS: Linux 4.10; UI render: default; VCL: gtk2; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-12-29_01:09:09 Locale: de-DE (de_DE.UTF-8); Calc: group threaded
*** Bug 115060 has been marked as a duplicate of this bug. ***
bbisect 5f1ebf0563dfa376c8ff949fce15616c8a29f41f is the first bad commit commit 5f1ebf0563dfa376c8ff949fce15616c8a29f41f Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Wed Feb 15 17:20:50 2017 -0800 source dc8ebf205c3231ffc4d6737b53cee396c2ac0bfd source dc8ebf205c3231ffc4d6737b53cee396c2ac0bfd author Xisco Fauli <anistenis@gmail.com> 2017-02-15 11:06:00 +0100 committer Miklos Vajna <vmiklos@collabora.co.uk> 2017-02-15 11:33:56 +0000 commit dc8ebf205c3231ffc4d6737b53cee396c2ac0bfd (patch) tree 10fb4e9a4d6bb474f4dd0144354df612d33ba38c parent 54c0b9977a6421ecb7383fa48636075c6ca9967e (diff) tdf#104315: Revert "tdf#44282 fix missing space... ... for numbered lists in TOC" This commit is causing lot of regressions in TOC. Besides, as the comment says, it's an ugly hack, so I'd prefer to revert it and find a better solution
The bisection in comment 5 is not correct, as the commit mentioned only reverts a previous commit. Regression introduced by: author Abhilash Singh <abhilash300singh@gmail.com> 2016-07-22 11:48:45 +0530 committer jan iversen <jani@documentfoundation.org> 2016-08-16 06:26:04 +0000 commit ce95e39f8e952159844e9dc04a1df402bb103634 (patch) tree dc419e5a1cb976ceab9867bd0b20612c8f8cf199 parent 989e8bc0d792f0dc5778746fac45de129a22d7ac (diff) tdf#44282 fix missing space for numbered lists in TOC Bisected with: Abhilash Singh Adding Cc: to bibisect-linux-64-5.3
I just did some checking on LO 6.0.1, and the bug is still there: an additional space still gets inserted when we update the ToC. I am sending this with the hope to place it back on your (collective) radar. Thank you very much for your consideration!
I did some additional testing with LO 6.0.3002, with the same outcome: an extra, unwanted space gets added to the TOC (and other indexes) when we update it. I was hoping the action described in Comment #6 would have addressed the situation, but apparently this is not the case. Thank you again for your help with this pesky issue!
Additional space is ugly. I think proper solution is tab stop in Bug 32360. Actual result (space is tied to chapter number): 2.1(space)Heading level 2 ................. 2(space)-1 Expected result (tab is entry in ToC structure): 2.1(tab)Heading level 2 ................. 2-1
I just did some testing using LO 6.0.6.2, to no avail: that pesky space keeps coming up. As I mention in related posts, the culprit was introduced in LO 5.3, while 5.2.7 was perfectly functional. I am hoping to revive this issue, so someone competent can address it, for everyone's benefit. Thank you very much!
@thomas: as far as I see, the space only is added after the second chapter number in the line, and only added once, not repeatedly? So update summary of this issue?
(In reply to Cor Nouws from comment #11) > @thomas: as far as I see, the space only is added after the second chapter > number in the line, and only added once, not repeatedly? > So update summary of this issue? The extra space always appears between the automatic number generated by Writer (as set by list or outline/chapter numbering) and the author-entered contents that follows. So if you have the punctuation input automatically by Writer, the extra space appears after that punctuation (e.g. "2. blahblah" > note that there are two spaces before blahblah); if you have the punctuation entered by the document's author, then the extra space appears before that punctuation (e.g. "2 . blahblah"). Does this clarify the issue?
(In reply to Cor Nouws from comment #11) > @thomas: as far as I see, the space only is added after the second chapter > number in the line, and only added once, not repeatedly? > So update summary of this issue? For, I see this extra space in every TOC line, not only once and not only after the second chapter. Therefore the summary is still valid.
This is more a cry for help than new input. New versions of LO keep rolling in while we can't still generate a valid ToC unless we stick to the LO 5.2.7 legacy version. Beyond the technical annoyance, this makes it difficult to promote LO as viable alternative for serious document writing. Thank you for anyone who could revive/fix that issue!!
I just did some check with LO 6.2.2.2. The same problem is there.
In LO 6.2.3.2, this "bug" persists. I do understand why the space after chapter number (E#) is default, but it should be possible to remove it. My document has three parts and every part has it's own paging. Due to the default space, it looks (A -1, A -2, ..., B -1, B -2, ..., C -1, C -2) not the way I want it to look (A-1, A-2, ..., B-1, B-2, ..., C-1, C-2).
(In reply to Cor Nouws from comment #2) > (In reply to Thomas Lendo from comment #0) > > Have you tested it with a different locale? > The problem does not appear in my LibreOffice. I see it now too in my version. Maybe I made a mistake first. Sorry in that case.
Patch introducing the problem is this one https://cgit.freedesktop.org/libreoffice/core/commit/?id=ce95e39f8e952159844e9dc04a1df402bb103634 Note: before that patch, there was no space between the chapter number and the chapter text. Which is annoying and much more prevalent than the example of this bug. It was a problem in OOo already (and is in AOO) See bug 44282 File with the code is here https://opengrok.libreoffice.org/xref/core/sw/source/core/tox/ToxTextGenerator.cxx?r=80cedb5d
This issue was introduced with version 5.3 of LO. It's possible that OO had it independently (I didn't verify) but LO 5.2.7 does not have this issue, while every subsequent version of LO has been affected by it to this day. If I could, I would pay to see it gone, so I can start promoting LO again as the best system to write long, structured documents (with ToCs and all).
Hi, Trying to revive this issue, which has not been fixed and continues to affect ToC generation. While I can't (unfortunately) help on the programming side, is there anything I could do so someone competent has a look at it? Thank you for your consideration.
Just adding a comment in the hope to bring this issue back into focus. I have been contacted about many bugs (most of them resolved) but this one remains significant.
*** Bug 145473 has been marked as a duplicate of this bug. ***
I therefore summarize the comments which converge in the same direction: - The systematic addition of a space before the chapter number (E#) in the table of content (TOC) is criticized because this character disrupts entries list. - It's a regression from a patch whose developer has not considered all potential downsides (#44282). - Solutions exist such as consistently adding a tab (#32360) or a space that can be removed, before the chapter number and for all levels, in the Structure and Formatting tab. It would be interesting to have the opinion of the team in charge of user interface on this matter. Thank you!
Putting this space into one of the text entry boxes of the Structure line would allow user control over this insertion. Everything which imposes a convention on user should be avoided. This is the case for this automatic space which can't be eliminated (I have cases where I end up with two spaces (one from the numbering style and the automatically added spece).
https://gerrit.libreoffice.org/c/core/+/147997 The implemented solution is: Keep the hack introduced in tdf#44282, but only add the space if the next token is "entry text", and also if the entry number does not end with a space or a tab. This allows the following situations: 1. The problem from bug 44282 - the existing ToCs without any space token between the number and the text will keep working as desired, with the space added automatically. 2. The problem from comment 0 (attachment 132787 [details]) had two problematic places: 2.1. There were two space characters inserted between [E#] and [E]. After updating, the ToC had three spaces between those elements. 2.2. There was a [E#]-[#] sequence. After updating, it was shown as 2 -1. Both problems get fixed, because in both cases, since the next element after [E#] is not [E], but a text (either two spaces, or a dash), the automatic space will not be added. 3. Comment 9 suggests a tab between [E#] and [E]. It is possible now, and again, since the next after [E#] will be [T], not [E], the automatic space will not appear. Whether it should become a default or not is a different thing, a topic for UX; I would think it's questionable, but technically no problem anymore. 4. Comment 24 also mentioned possible spaces as a postfix of the number itself, which would result in a double space. Since the change checks the last character of the number, this will also prevent the extra space. Wrt #3, I think that an alternative solution (mentioned in comment 23) - i.e., having the *space* explicitly between [E#] and [E] by default - is not optimal, because visually, the empty text placeholder between those elements is indistinguishable form the placeholder with a space character. All in all, I hope that this will be clever enough to avoid 99.9% of possible problems; I consider a wish to really have the number merged to the following entry text (which is impossible in the current and new situation) to be ~improbable to consider.
(In reply to Mike Kaganski from comment #25) > I consider a wish to really have the number merged to the > following entry text (which is impossible in the current and new situation) > to be ~improbable to consider. On the second thought, having a WJ there between [E#] and [E] would allow even that.
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/b7a5ac03e03066d36e05da786669a9243ad0116f tdf#114773: only add space between entry number and text It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-7-5": https://git.libreoffice.org/core/commit/5e6597d4a0b5035df080830733697c46343f3fbb tdf#114773: only add space between entry number and text It will be available in 7.5.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Mike Kaganski from comment #25) > All in all, I hope that this will be clever enough to avoid 99.9% of > possible problems. At least for my simple test case with the [E#]-[#] sequence (and using Levels 1-3), the extra space after E# is gone! Thanks for fixing this Mike!
Verified with attachment 132787 [details] from original bug report and Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: d7c609dbb1bd08865b43719d2fb7c316d30bcde5 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: en-US (de_DE); UI: en-GB Calc: CL threaded Mike, thank you for fixing it!
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/d899cc680b7a0a21d863a1e1746262bf958de882 tdf#114773: sw_uiwriter3: Add unittest It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Using build https://gerrit.libreoffice.org/gitweb?p=core.git;a=log;h=ee5dbd193fa24b46fb980ddd8a6c39ca349d0d01 (I'm using the Unix version [deb]) The TOC no longer has that extra space. Thanks for fixing this.