Created attachment 148744 [details] Screenshot showing the behaviour The TOC in the .odt document I am working on since months again shows lines which only contain dots. This affects entries in the TOC of levels 1 and 2. My document contains only the first and the second heading level. For demonstration purposes, refer to the attached screenshot. In the TOC settings on the "Entries" tab, all levels are connected with the character style "None". If I change the character style of level 1 or level 2 to the character style "Default style", then the behaviour described above does not get resolved. By the way, if I then again open the "Entries" tab in the TOC settings, the character style has been set back to "None" for level 1 and level 2. I can easily provoke this behaviour. If I change the text of heading "'Nominelle' Mitgliedschaft in der NSDAP. Falsche Angabe über den Zeitpunkt des Eintritts in die NSDAP" (the behaviour does not occur with this length of this heading) to "'Nominelle' Mitgliedschaft in der NSDAP. Falsche Angabe über den Zeitpunkt" (i.e. I deleted the last three words of that heading) , then the behaviour occurs, as it is visible with this shortened heading in the attached screenshot. I am using Linux Debian 9.7 ("Stretch"9), the currently stable Debian release. I cannot upload the affected file here because it contains personal data about my family.
Created attachment 148745 [details] .odt file showing the behaviour (on my machine)
I have created a new .odt document containing only the headings which you can see in the attached png file (screenshot). The behaviour occurs in this new .odt. file, too. I have attached this new .odt file. Basic information about how I set up my LO writer installation can be found in the attached .odt file.
Please note that before I inserted the respective text strings of the headings from the original .odt document (which I do not want to upload here) into the new .odt file (which is attached to this bug report), I copied these headings from the original .odt file into a text editor programme and then from the text editor programme into the new .odt file. I did this to prevent heading formattings being transferred from the original .odt document to the new .odt document.
I confirm the behaviour, but it is what I would expect: Heading is too long, so page number has to move to the next line. The space between end of heading and page number is filled with dots. So my question is: What do you expect? For me NOTABUG
(In reply to Dieter Praas from comment #4) > I confirm the behaviour, but it is what I would expect: Heading is too long, > so page number has to move to the next line. The space between end of > heading and page number is filled with dots. So my question is: What do you > expect? For me NOTABUG If you look at the screenshot which I attached to this bug report, you should notice the erroneous behaviour regarding the automatic creation of text lines in TOC´s: A whole line in a TOC containing only dots and a page number at the end of the line looks ugly and nonprofessional. This is no expected behaviour. The error is that, if the heading is exactly as long as one line in the TOC, this line does not get a line break after, let's say 3/5th of the length of the line, which would bring the remaminig 2/5th of the line to the next line in the TOC. I noticed this behaviour with headings of level 1 and 2 so far. For me this is a bug.
(In reply to Jens Radloff from comment #5) > A whole line in a TOC containing only dots and a page > number at the end of the line looks ugly and nonprofessional. I agree, but you can change this manually. > The error is that, if the heading is exactly as long as one line in the TOC, > this line does not get a line break after, let's say 3/5th of the length of > the line, which would bring the remaminig 2/5th of the line to the next line > in the TOC. Yes, but why 3/5th and not 3/4th or why not justified? For me still NOTABUG or WONTFIX, but let's ask design team.
(In reply to Dieter Praas from comment #6) > I agree, but you can change this manually. How would you do it? I was expecting that indentation at right makes the line break, which does happen but then the page numbers are indented as well. The solution could be to right align the page numbers independently from the indentation but that's a regression for users who wants the number to be indented. Regina, what do you think?
(In reply to Heiko Tietze from comment #7) > (In reply to Dieter Praas from comment #6) > > I agree, but you can change this manually. > > How would you do it? 1. Edit index => Type => disable "Protect against nmanual changes" => OK 2. Line break
Manual changes will be lost on next update of the index. I do not recommend it. I think, the line break in the index could be improved. The available room for the entry text could be calculated excluding the line number, for example. So the last word would go to the next line earlier. The visual problem is, that the text of the entry reaches into that area, which contains the page numbers in the other lines. For me a valid enhancement request. Workaround: Add two non-breaking spaces to the end of the heading itself for those headings, which have this problem in the index. The additional space between entry text and leader dots in the index is acceptable, because the dotted line is still very long.
Neither linebreak nor a modified calculation seems to be a proper solution to me. We have to modify the used styles and those have to work in other scenarios as well (eg. applying to ordinary text).
(In reply to Regina Henschel from comment #9) > Manual changes will be lost on next update of the index. That's true, but I think it is actual the only possibility to get a good layout. Is it possible to have an option that "update index" only updates headings and page numbers but not the style? I would prefer such a solution.
Created attachment 148857 [details] Solution by design Talked with Regina again. If we change the implementation and exclude, for example, the page number from the width calculation, we loose the cross-application compatibility and cannot guarantee consistent documents. Good news is that our workflow provides means to deal with the problem. Likewise adding non-breakable spaces to the headline you can also modify the entry style and insert some dots by default. The screenshot illustrates the idea.