Summary: | Table of Contents - "Tab position relative to paragraph style format" stops working | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | Frank Zimmerman <fz1844> |
Component: | Writer | Assignee: | Not Assigned <libreoffice-bugs> |
Status: | NEW --- | ||
Severity: | normal | CC: | fz1844, mikekaganski |
Priority: | medium | ||
Version: | 6.4.4.2 release | ||
Hardware: | x86-64 (AMD64) | ||
OS: | Windows (All) | ||
See Also: | https://bugs.documentfoundation.org/show_bug.cgi?id=76005 | ||
Whiteboard: | |||
Crash report or crash signature: | Regression By: | ||
Bug Depends on: | |||
Bug Blocks: | 89606 | ||
Attachments: |
This is the Document with the wrong formatting in the Table of Contents
This is a Copy of the Document which shows the correct TofC formatting Here is a sample DOCX file that breaks the TOC indenting when inserted into an ODT |
Description
Frank Zimmerman
2020-07-12 06:41:53 UTC
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. |