Create a new document with some paragraphs with 'Heading 1' style; Insert outline numbering for 'Heading 1' paragraphs (Tools > Outline Numbering... ; Number field to '1, 2, 3, ...'), click OK; Insert a TOC (Insert > Indexes and Tables > Indexes and Tables), click OK; In the new TOC, there isn't space between text and number. The workaround that I use is insert a space between <e#> and <e> in the structure of all entry levels of TOC. But I think Writer can do it automatically. Thanks! Gustavo Pacheco.
Please, attach small document that demonstrates this problem
Created attachment 57513 [details] Example document demonstrating the bug
The bug has been annoying OO.o (and maybe even Staroffice) users for years. There is a workaround (adding a space in Index/Table settings) but by default there should be a space. A lot of users have asked about this: https://www.google.com/search?q=openoffice+toc+space+between
The same in the 3.5.3.2 on Ubuntu 12.04 Really annoying.
Thanks for attachment, workaround, and additional information. It is enhancement request because Writer works correctly, at least formally. But productivity may be increased. Another question: what to add, space or tab? If space, then how much? If tab then on which distance? 0.5 cm looks reasonable for me.
I have inserted one space - and it looks very well. But there is a small problem with this workaround: I have two chapters in the beginning without numbers (anтotation and introduction) if I insert a space it also affects them - they start not from the beginning of the line, but after the space. Of course it is much more better, than it was before without space but does not look perfectly.
Created attachment 61834 [details] Example with space
Created attachment 61835 [details] The same example, but with tab 0,5 cm instead of space
Looks much more better with tab! But shouldn't be lines without numbers left aligned as the numbered lines? I think this variant will be correct. But your with tab is also very good.
*** Bug 81981 has been marked as a duplicate of this bug. ***
Hello ,I am a rookie and want to solve this as my first easy bug hack. Can any body give me idea how should I procede. Thanks in Advance.
Hi Lovekesh, (In reply to Lovekesh Garg from comment #11) > Hello ,I am a rookie and want to solve this as my first easy bug hack. > Can any body give me idea how should I procede. Nice. Look here http://wiki.documentfoundation.org/Development and don't forget to use e.g. opengrock. Cheers, Cor
(In reply to ababaaa from comment #11) > Hello ,I am a rookie and want to solve this as my first easy bug hack. > Can any body give me idea how should I procede. > Thanks in Advance. See OUString SwTextNode::GetExpandText() in sw/source/core/txtnode/ndtxt.cxx and TextAndReading SwTOXPara::GetText_Impl() in sw/source/core/tox/txmsrt.cxx.
Migrating Whiteboard tags to Keywords: (EasyHack DifficultyEasy SkillCpp) [NinjaEdit]
JanI is default CC for Easy Hacks (Add Jan; remove LibreOffice Dev List from CC) [NinjaEdit]
Hello, I want to fix this bug
I'm new to libreoffice, I'm planning to solve it as my first easyhack
Mohamed Thabet committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=9ebe054ddb2d938b24ca4688be9bcbc62745f67f tdf#44282 fix missing space for numbered lists in TOC It will be available in 5.2.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.
Thanks for taking the time to fix this. I built LO from master, opened the three attached example files, then updated the TOC. Results are: toc-bug.odt: TOC contains numbers and text without any spacing: "1Foo". Paragraphs contain a tab between the number and text: "1\tFoo". After updating the TOC there is a space between the number and text: "1 Foo". toc.odt: TOC contains a space between the numbers and text: "1 Eins". Paragraphs contain a tab between the number and text: "1\tEins". After updating the TOC there are two spaces between the number and text: "1 Eins" toc-tab.odt: TOC contains a tab between the numbers and text: "1\tEins". Paragraphs contain a tab between the number and text: "1\tEins". After updating the TOC there is a space and a tab between the number and text: "1 \tEins" If we take a step backwards, Writer should take it into consideration - what is already imported in the TOC, - what is set as a separator for the given level of numbering in the Bullets and Numbering window, Position tab, "Numbering followed by" dropdown, which has three possible values: Tab stop, Space, Nothing. I think just blindly inserting a space is not the right thing.
Created attachment 123705 [details] Updated TOC of toc-bug.odt
Created attachment 123706 [details] Updated TOC of toc.odt
Created attachment 123707 [details] Updated TOC of toc-tab.odt
Created attachment 123708 [details] List of possible separators between the numbering and text
Thank you for the detailed feedback, I will take the two points you mentioned into consideration and will try to work on it again.
jan iversen committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=0149e87df9f09f325f8a04f495d561b8deb1e625 Revert "tdf#44282 fix missing space for numbered lists in TOC" It will be available in 5.2.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.
Regarding the first point, I think if there is already a tab token added to the table of contents like the work around, and the number token has a separator after it, the normal behavior would be having two consecutive separators, is that right? I made some progress, I can now insert the correct separator according to the list, and the option: "format: number without separator" now works for the number token. there is still a problem when the list separator is a tab, where not defining a the correct tab stop position would expand the tab into dots, but I'm still looking into it.
(In reply to Mohamed Thabet from comment #26) > Regarding the first point, > > I think if there is already a tab token added to the table of contents like > the work around, and the number token has a separator after it, the normal > behavior would be having two consecutive separators, is that right? > No, because in the next "open document - refresh index" cycle there will be two tabs in the index, so you would add one more to make it three. For inspiration, Word replaces the separator in the index with the one set in the header text. If you have a tab separator in the index, then you change the separator to space in the text and update the index, there will be one space in the index too. So the index always follows the text.
That word like behaviour is exactly what I'm aiming for. I just need to clarify that the table of contents doesn't accumulate separators, in each table update it works like the first time, so doing the open document and update cycle won't add a third separator, what I mean by having two separators is having: - the separator followed by the number - the separator from the workaround. so - exculding the use of a differnt separator - the "Updated TOC of toc-tab.odt" attachment works like expected, there is a number separator then there is the user added tab, updating the table of contents won't add any more separators.
A polite ping, still working on this patch?
Currently I'm not working on it, I couldn't replicate the behavior of numbered lists in the table of contents when the separator was a tab.
I'm new here and want to solve this bug. I've understood the bug and have even replicated it. I took a look at one of the patches in the comments(which seems to not account for all the cases). Comment 19 explains what actually needs to be done and I quote a part of it here - "If we take a step backwards, Writer should take it into consideration - what is already imported in the TOC, - what is set as a separator for the given level of numbering in the Bullets and Numbering window, Position tab, "Numbering followed by" dropdown, which has three possible values: Tab stop, Space, Nothing." Can I know where should I look for the code related to the two points mentioned in the above comment?
(In reply to Raj Sarkar from comment #31) > I'm new here and want to solve this bug. I've understood the bug and have > even replicated it. I took a look at one of the patches in the > comments(which seems to not account for all the cases). > > Comment 19 explains what actually needs to be done and I quote a part of it > here - > > "If we take a step backwards, Writer should take it into consideration > - what is already imported in the TOC, > - what is set as a separator for the given level of numbering in the Bullets > and Numbering window, Position tab, "Numbering followed by" dropdown, which > has three possible values: Tab stop, Space, Nothing." > > Can I know where should I look for the code related to the two points > mentioned in the above comment? Welcome, in general have a look at: https://wiki.documentfoundation.org/Development/GetInvolved Code pointers are found in comment #18, That patch was good, but had some side effects, so the easiest way is to take the patch, test it, and correct it. The problem the patch introduced was around outlining at higher levels than 2.
Abhilash Singh committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ce95e39f8e952159844e9dc04a1df402bb103634 tdf#44282 fix missing space for numbered lists in TOC It will be available in 5.3.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.
(In reply to Commit Notification from comment #33) > Abhilash Singh committed a patch related to this issue. > It has been pushed to "master": > > http://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=ce95e39f8e952159844e9dc04a1df402bb103634 > > tdf#44282 fix missing space for numbered lists in TOC > > It will be available in 5.3.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. Thanks for trying to fix this problem. I have built the 5.3 master branch, and the situation is the same as with the earlier patch: a space separator is always added. So after updating the TOC there is one space separatop in toc-bug.odt, two spaces in toc.odt and a space and tab in toc-tab.odt.
Created attachment 126860 [details] Screenshot of the example documents TOCs with the new fix
*** Bug 103149 has been marked as a duplicate of this bug. ***
@abhilash, Can you please look at comment #34 and 35? Thanks for your efforts on this issue - great to see progress! Ciao - Cor
Thanks for pointing out. I agree. The previous patch added a space irrespective of the fact whether or not numbering was done( For example - in attached file toc.odt, the previous patch also added a space to Heading-1 "Null" which wasn't even numbered and hence didn't require spacing. Comment 6 mentions the same problem). My patch merely made sure that spacing is applied only when numbering is available( leaving the Heading 1 "Null" in toc.odt and taking care of all other Headings). So, what in addition needs to be done is - if the user has specified something between <E#> and <E> ( a space or some other character ) we don't need the default spacing to be applied. And in all other cases we need the default spacing to be applied. Is that so? Please confirm, and I will commit a patch soon accordingly. Thanks.
(In reply to abhilash300singh from comment #38) > So, what in addition needs to be done is - if the user has specified > something between <E#> and <E> ( a space or some other character ) we don't > need the default spacing to be applied. And in all other cases we need the > default spacing to be applied. Is that so? Indeed, perfect. > Please confirm, and I will commit a patch soon accordingly. Thanks a lot!
Please don't forget to insert back the space, when a different separator gets deleted again. :)
(In reply to zyklon87 from comment #40) > Please don't forget to insert back the space, when a different separator > gets deleted again. :) I tested this. The case statements seem to take care of this themselves.
Abhilash committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=250252d02bac88877845a4bc27e3f1837f1312ba tdf#44282 fix missing space for numbered lists in TOC It will be available in 5.3.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.
Seems solved.
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=dc8ebf205c3231ffc4d6737b53cee396c2ac0bfd tdf#104315: Revert "tdf#44282 fix missing space... It will be available in 5.4.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.
Moving back to NEW as the commit has been reverted due to the fact that it introduced some regressions in TOC
Adding a space or any other character is not the right way of formatting. If the default of the style "Contents 1" (and below) is 0 for all indentation this property should be changed to something like 0.5/-0.5 for before text/first line.
Xisco Fauli committed a patch related to this issue. It has been pushed to "libreoffice-5-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=05116fb49efa563610f6486d0c3f6216624dcd13&h=libreoffice-5-3 tdf#104315: Revert "tdf#44282 fix missing space... It will be available in 5.3.1. 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.
I am starting to work on this bug.
Created attachment 132787 [details] Test file showing additional space after chapter no. in ToC In 5.3.1 an additional space after the chapter number in a Table of Content was introduced. You can test it with the attached document. Illustration and table indexes are not affected. 5.3.0 wasn't affected. 5.3.2 is also affected. Actual result: 2.1 Heading level 2 ................. 2 -1 Expected result: 2.1 Heading level 2 ................. 2-1
A polite ping, still working on this bug
A polite ping, still working on this bug?
For me, this works OK in Version: 6.1.0.0.alpha0+ Build ID: a9b202a6b7000e7af34f2a639ca207122a3968bf CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk2; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-12-26_23:09:36 Locale: nl-NL (nl_NL.UTF-8); Calc: group threaded as well as in Versie: 6.0.0.1 Build ID: d2bec56d7865f05a1003dc88449f2b0fdd85309a CPU-threads: 4; Besturingssysteem: Linux 4.13; UI-render: standaard; VCL: gtk2; Locale: nl-NL (nl_NL.UTF-8); Calc: group So I set as WorksForMe Thanks a lot for all that worked on this - whether the code made it to the repo or not!
(In reply to Cor Nouws from comment #56) > For me, this works OK in Version: 6.1.0.0.alpha0+ [..] > as well as in Versie: 6.0.0.1 [..] Set back to NEW as I sadly can't confirm that this bug is fixed. Version: 6.1.0.0.alpha0+ Build-ID: 38f5e768b0f858f8f990a8f297396821c75d45dc CPU-Threads: 4; BS: Linux 4.10; UI-Render: Standard; VCL: gtk2; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-12-29_01:09:09 Gebietsschema: de-DE (de_DE.UTF-8); Calc: group threaded and Version: 6.0.0.1 Build-ID: d2bec56d7865f05a1003dc88449f2b0fdd85309a CPU-Threads: 4; BS: Linux 4.10; UI-Render: Standard; VCL: gtk2; Gebietsschema: de-DE (de_DE.UTF-8); Calc: group
Referring to the additional space after the chapter number mentioned in comment 49.
Hi Thomas, (In reply to Thomas Lendo from comment #58) > Referring to the additional space after the chapter number mentioned in > comment 49. The reported bug was Actual result: 2.1Heading level 2 ................. Expected result: 2.1 Heading level 2 ................. That is resolved. What you describe in comment #49 is a different bug (one that I don't see, by the way). Please fine a new issue for that. Thanks - Cor
I created Bug 114773 "TOC: Remove additional space after chapter number in ToC". Hopefully somebody interested in fixing this bug can also have a look at the other one. It's a very small issue, but a visible one for documents with ToC. Thanks, Thomas.
*** Bug 62952 has been marked as a duplicate of this bug. ***
Ugh... so instead of fixing the default entry in the ToC, adding a space there (so that when users create ToC, the space is there), this introduced a hack to try to be more clever than users? Adding spaces when users don't add them?