Description: The documents I create usually have two levels in the Table of Contents: chapter items (which are numbered), and subtitles. The subtitles are based on a paragraph style with and indent on the right side, so that when the Contents is generated, the subtitle page numbers will be indented from the Chapter page numbers. Sometimes, this stops working, and all of page numbers are right-aligned to the edge of the page. This has happened a few times over the last few years, so it is not specific to the current release. I am now able to provide some sample documents, so I am filing this bug report. Unfortunately, I don't know what steps are required to reproduce it. But I can tell you how I created the first sample document (which shows the problem). I use a template with pre-defined styles for paragraph, character, page, and numbering. This template already has a Table of Contents inserted, and a dummy chapter heading. 1. Tonight I created the first document from the template, and then inserted the basic book from a plain text file. 2. I then inserted a few Word docs in the middle of the text, using the "Insert->Text from File..." command. Some of these docs had columns which created Sections, but I deleted all the sections to remove the columns. 3. After marking the chapter headings and Subtitles with the proper Paragraph styles, I updated the Table of Contents, and voila!...indentation problems; the subtitle page numbers, which should have been indented on the right side by about 1/4 inch, were right aligned to the page. I tried changing various settings in the Table of Contents and in the Paragraph and Character styles but nothing worked. 4. I then created a new Document from the same template, and copy/pasted the chapters, one-by-one, over to the new document, updating the Table of Contents after each chapter was inserted, to see if it broke. It did not break, and looks just fine. 5. I then took the original Document with the problem, and tried "Load Styles..." from the working document, telling it to overwrite all of them (Page, Character, Paragraph, etc.). This did not change the original Document, it still failed to align the subtitle page numbers properly. So I'm guessing at this point that there may be some kind of corruption going on in the Document, or perhaps some invisible characters, that causes the Table of Contents to fail the alignment. I'm including both Documents, so someone else with deeper knowledge of the inner workings can analyze them to see what is different. Steps to Reproduce: See the Description. Actual Results: Level 2 Subtitle page numbers are right-aligned to the Page Text area in the Table of Contents. Expected Results: Level 2 Subtitle page numbers should be indented by 1/4 inch from the right of the Page Text area in the Table of Contents. Reproducible: Sometimes User Profile Reset: No Additional Info: I thought that once in the past I was able to fix this problem but can't remember what I might have done. It could have involved taking out the breaks before Chapter headings and re-implementing them...not sure. Hopefully someone can compare the two documents to see what is the difference.
Created attachment 162915 [details] This is the Document with the wrong formatting in the Table of Contents
Created attachment 162916 [details] This is a Copy of the Document which shows the correct TofC formatting This Document was created from the same template, and then one-by-one, the chapters were pasted in, and the Contents updated. It works perfectly, but is almost identical to the Document that doesn't work.
I can see the difference in both documents, but I couldn't find out, what causes the difference: Settings in Index are the same and settings of the paragraph style are also the same. Perhaps anybody else can help
Thanks for looking at it. This evening I got out the Meld program, and extracted the contents of both ODT's. There were a few differences, but nothing that stood out to me. So I started swapping over various elements. I tried the Styles.xml from the working doc to the non-working doc. Zipped up, renamed to ODT, but it didn't change. I tried it the other way around, didn't break the good one. Next I tried the Contents.xml and went both ways with that. Again, same results. Did not break the working doc, and did not fix the broken one. Next I tried both Contents and Styles XML. Same results. Finally I tried the Settings.xml and this made all the difference. If I take the Settings.xml from the broken doc and put it in the good one, it breaks it. If I take the Settings.xml from the good doc and put it in the broken one, it fixes it. There are some interesting differences between the two. Some of the differences seem to come from the import of Word Docs, which I used to create the original non-working ODT (whereas the working ODT was created by copy/paste of text from the non-working ODT. In the Properties for the non-working ODT, the Template (in the General tab) shows as "Normal.dotm". In the working ODT, it shows my LibreOffice template "PP Book Template". More interesting, there were some "Custom Properties" defined in the non-working ODT, which I guess were imported from the Microsoft Word files. I deleted all these custom properties, but the TOC still does not format correctly. And other than those Custom Properties, I can't see any other differences in the Properties dialog itself. Next I did a MELD on the two Settings.xml files (after running XML Tidy on them first!). Here are the properties that are different, between the two docs. This first set have different integer values. I'm not listing the values for these, as I'm not sure they are relevant. ViewAreaTop ViewAreaLeft ViewAreaWidth ViewAreaHeight ViewLeft ViewTop VisibleTop VisibleRight VisibleBottom This next structure is only in the non-working doc: ForbiddenCharacters - Language: en - Country: US - Variant: - BeginLine: - EndLine: These next properties are in both docs, but in the non-working one, they have the following values (and in the working one, the opposite values): FloattableNomargins: true UnbreakableNumberings: true AddVerticalFrameOffsets: true BackgroundParaOverDrawings: true DoNotJustifyLinesWithManualBreak: true DoNotCaptureDrawObjsOnPage: true EmbedSystemFonts: true AddFrameOffsets: true ConsiderTextWrapOnObjPos: true TableRowKeep: true TabsRelativeToIndent: false IgnoreTabsAndBlanksForLineCalculation: true InvertBorderSpacing: true ClippedPictures: true TabOverMargin: true TreatSingleColumnBreakAsPageBreak: true SurroundTextWrapSmall: true ApplyParagraphMarkFormatToNumbering: true There was also an "Rsid" property that had a different value between the two docs, but this is just a long integer, so I don't think it will affect the formatting of the TOC. I'm pretty sure it is one of the boolean properties that is causing the mess-up. I could now test each one to find out which it is (or it may be a combination of more than one) but it would be nice if we could get someone involved who has more knowledge about the Settings.XML file, who might be able to hone in on just which of these is the culprit. I believe that these properties got set from the import of Word DOC (or DOCX) files, into the original (non-working) ODT. So it could potentially affect other people's documents as well, and this import process needs to be looked at, so a property is not carried over that breaks indenting in the Table of Contents.
Okay, I couldn't resist trying the one obvious property: TabsRelativeToIndent I changed that to True, then loaded the ODT. Now I had indenting again in the TOC, but the first-level items were going past the margin. So I changed one other property: TabOverMargin I changed that to False, and the document TOC now works correctly. So it is (at least) a combination of those two. I'm not sure how the other ones could affect it in different situations.
@ Mike Kaganski: Mike, I've learned from bug 134738, that you are familiar with tabs in TOC. Perhaps you can have a look at this bug report? Thanks in advance.
Yes this looks like it should ignore TabOverMargin in indexes.
(In reply to Mike Kaganski from comment #7) > Yes this looks like it should ignore TabOverMargin in indexes. (at least for "Tab position relative to paragraph style format" case)
TabOverMargin only makes sense in the context of MS formats, and in that case you can test again how Microsoft Word handles the document in order to determine what "ought" to happen. [So I don't think you can say what should or should not happen in these indexes unless you convert this document to docx first, and find that the same expectations hold true.] But yes, when you start off with an MS format, you inherit all of the quirks that are needed to support it. And TabOverMargin definitely is quirky.
A *different* bug is if this setting somehow gets applied to an existing document because of user actions (there's no UI to set it, and it only should appear in documents initially created from MS Word document types; so operations like copy of external content to already existing document, previously having not it set, should never change it).
I've done a bit more testing. I can take the ODT that is working (with the properly indented TOC), and as soon as I use the "Insert->Text from File..." command, and insert a DOCX file (without any TOC, just one chapter), it breaks the Table of Contents in the ODT. So it does not have to be an ODT created from a DOC or DOCX, simply importing the DOCX is enough to break the ODT. If the working ODT (with no imported DOC files) is imported into MS Word, and the TOC is refreshed, all levels of the page numbers are right-aligned. If I export the ODT to a DOCX and then open it in MS Word and refresh the TOC, all levels of the page numbers become right-aligned (although before updating, they have the proper levels of indentation). The only thing I haven't tried is setting up a Word DOC with indented TOC levels, and then trying to export ODT, or import the DOCX into LibreOffice. However, that is not what I am doing here. The breakage took place just by importing one chapter in DOCX format, without any TOC involved.
Maybe that last line wasn't so clear. The DOCX file that I imported had no table of contents, it was just rough RTF type formatting. It was only one chapter worth of text. As soon as I imported it into a blank page, and before I applied any of my styling to it, the TOC was broken when refreshing. So: 1. Import the DOCX using "Insert->Text from File" 2. Refresh the TOC 3. Indenting is broken. I can attach one of the DOCX files I'm using, if it would help.
I can add one more detail. For the bulk of the text I used to make the ODT, most of it came from plain text files (no formatting, just TXT). I then applied chapter headings, paragraph formatting styles, etc. And the TOC was generated from the chapter headings and sub headings (Level 1 and 2). But there were four chapters missing from the TXT file, which I obtained in PDF format, from scans of an old periodical magazine. I processed these four PDF's using ABBY Fine Reader, and saved the text as DOC. I then fixed some of the formatting in MS Word, and saved each chapter as a separate DOCX file. It was these four DOCX files that I then imported into the ODT, which broke the TOC. Even importing just one of the files will break the ODT (as I just confirmed).
Created attachment 163953 [details] Here is a sample DOCX file that breaks the TOC indenting when inserted into an ODT 1. Take a working ODT with TOC based on Level 1 and 2 (chapter headings and sub-headings). 2. The TOC has "Tab position relative to paragraph style indent" and the subheading paragraph style has .25" right indentation (so the page numbers in the TOC for the subheadings will be indented from the right edge). 3. Go to a blank page in the ODT and insert this DOCX file using the "Insert->Text from File" command. 4. Now refresh the TOC. The indentation will be lost.
Dear Frank Zimmerman, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
I've just tested now, and I can confirm that the bug still exists in LO 7.3.5.2, after importing a Word Doc file using "Insert->Text from file...", and that changing the two properties TabsRelativeToIndent and TabOverSpacing in the Settings.xml file fixes it again.