Bug 115798 - Table of Contents entries (made with Insert Index Entry) are moved when saving in .docx format
Summary: Table of Contents entries (made with Insert Index Entry) are moved when savin...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.3.7.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: DOCX-TableofContents
  Show dependency treegraph
 
Reported: 2018-02-17 10:35 UTC by Fredrik Jansson
Modified: 2021-02-28 04:00 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
First few steps of reproduction, file creation (2.39 MB, image/bmp)
2018-02-18 00:13 UTC, Fredrik Jansson
Details
Following steps of reproduction, creating of Table of Contents (4.69 MB, image/bmp)
2018-02-18 00:15 UTC, Fredrik Jansson
Details
Few more steps of reproduction, writing lines and adding them to ToC, updating ToC and saving file (16.44 MB, image/bmp)
2018-02-18 00:18 UTC, Fredrik Jansson
Details
Last step, outcome of Table of Contents (6.98 MB, image/bmp)
2018-02-18 00:20 UTC, Fredrik Jansson
Details
example file, created from the method described in .bmp's (10.96 KB, application/vnd.oasis.opendocument.text)
2018-02-18 00:21 UTC, Fredrik Jansson
Details
example file, Faulty Table of Contents saved from the .odt example file (4.54 KB, application/zip)
2018-02-18 00:22 UTC, Fredrik Jansson
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Fredrik Jansson 2018-02-17 10:35:12 UTC
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
Comment 1 Thomas Lendo 2018-02-17 22:15:48 UTC
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.
Comment 2 Fredrik Jansson 2018-02-18 00:13:44 UTC
Created attachment 139964 [details]
First few steps of reproduction, file creation

Create a new LibreOffice Writer file (.odt), open it.
Comment 3 Fredrik Jansson 2018-02-18 00:15:26 UTC
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.
Comment 4 Fredrik Jansson 2018-02-18 00:18:01 UTC
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
Comment 5 Fredrik Jansson 2018-02-18 00:20:27 UTC
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
Comment 6 Fredrik Jansson 2018-02-18 00:21:30 UTC
Created attachment 139968 [details]
example file, created from the method described in .bmp's

Working .odt that shows the Table of Contents as expected
Comment 7 Fredrik Jansson 2018-02-18 00:22:21 UTC
Created attachment 139969 [details]
example file, Faulty Table of Contents saved from the .odt example file
Comment 8 Imai 2018-02-19 06:54:28 UTC
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
Comment 9 Thomas Lendo 2018-03-05 00:01:57 UTC
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
Comment 10 QA Administrators 2021-02-28 04:00:23 UTC
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