Description: Noticed when I've created a ToC - after converting from .odt to .docx, LibreOffice changes the levels of items in the ToC every save. It also marks the ToC posts badly in .docx format, it only shows the mark right after the text. Originally noticed on 5.3.7, exists in 6.1. This does not happen in .odt format Steps to Reproduce: 1. create a .odt file 2. add a Table of contents and some entries 3. save file as .docx 4. open new file, update index - entries will move down one level, save 5. open new file, update index - entries will move again Actual Results: entries will move one level down per save Expected Results: entries should stay at their level they were created at when updating Reproducible: Always User Profile Reset: No OpenGL enabled: Yes Additional Info: User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko
Hi Fredrik, thanks for your bug report. I can't reproduce any change. Can you explain more clearly what you mean with "entries move down"? Please attach sample file(s) and/or screenshots showing the ToC before and after. I set the bug into status NEEDINFO. When you provide files or screenshots, please change back to UNCONFIRMED.
Created attachment 139964 [details] First few steps of reproduction, file creation Create a new LibreOffice Writer file (.odt), open it.
Created attachment 139965 [details] Following steps of reproduction, creating of Table of Contents press add Table of Contents, register, index. Select Table of Contents, press OK.
Created attachment 139966 [details] Few more steps of reproduction, writing lines and adding them to ToC, updating ToC and saving file Write 3 lines. Mark the first line, press "insert post" (roughly translated) add it at level one select next line - update line entry and add it at level two select next line - update line entry and add it at level three Right-click the Table of Contents and select "Update". Compare result and save file as .docx
Created attachment 139967 [details] Last step, outcome of Table of Contents When opening the new .docx file, the Table of Content entries has their linenumbers badly aligned, aswell as the marker text for the entries is not on the actual text. Updating the Table of Contents fixes the spacing, but lines have moved: "Line 1, level 1" has now been placed on level two "Line 2, level 2" has now been placed on level three "Line 3, level 1" has now been placed on level two Saving the file and reopening shows the same problem, updating the Table of Contents moves lines even further
Created attachment 139968 [details] example file, created from the method described in .bmp's Working .odt that shows the Table of Contents as expected
Created attachment 139969 [details] example file, Faulty Table of Contents saved from the .odt example file
Issue not reproduced. OS X EL Capitan Ver:10.11.3 version: 6.0.1.1 Build ID: 60bfb1526849283ce2491346ed2aa51c465abfe6 CPU threads: 4; OS:Mac OS X 10.11.3; UI render: default; local: ja-JP (ja.UTF-8); Calc: group
Thank you, Fredrik. It was a little tricky as I don't understand your GUI language, but I can reproduce the issue. It only occurs if you use the Insert Index Entry command [1], not if you have headings. [1] https://help.libreoffice.org/4.3/Writer/Insert_Index_Entry
Dear Fredrik Jansson, 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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Created attachment 174026 [details] The exported and original document side by side in Writer Still a problem in: Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 7c38362dbe1922c9825dffb463072030948d406b CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win Locale: en-US (hu_HU); UI: en-US Calc: CL