Created attachment 118748 [details] Sample file contains only 2 lists My odt file contains 2 lists: List 1 and List 2. They are listed as followed: List 1 1. item 1 2. item 2 3. item 3 List 2 1. item 1 2. item 2 3. item 3 When I saved as "Microsoft Word 2007/2010/2013 XML(.docx)". It listed as followed: List 1 1. item 1 2. item 2 3. item 3 List 2 4. item 1 5. item 2 6. item 3 List 2 numbering is continued from the List 1. I expect List 2 numbering to start from 1. See list-numbering-to-export.odt attached as an example.
Bug needs confirmation before being marked as NEW. Status -> UNCONFIRMED
Reproduced. Kubuntu 15.04 64-bit KDE Plasma 5.4 Version: 5.0.2.2 Build ID: 00m0(Build:2) Locale: en-US (en_US.UTF-8)
Regression with the attached document. Not reproduced from scratch.
Adding keyword 'bibisectRequest' to see whether this regression is already present in the oldest build of bibisect-43all repository or not. In case it's already present, change 'bibisectRequest' to 'preBibisect'. Otherwise, change 'bibisectRequest' to 'bibisected' and add a comment with the output from 'git bisect log'
I don't know if this is worth bibisecting and possible. We should've figured out how this specific document was created, because this is not reproducible creating those lists from scratch. xuanngo, can you help please?
@Timur I no longer remember how this doc is created. I'm therefore closing this bug.
Thank you. As a note, I tried creating from scratch with 4.3.2.2 on Windows and with 5.0. in Linux and couldn't reproduce. Maybe it's about some combination, maybe about the exact steps how it was created. ODT itself also seems not valid, when looked directly. It's true there is sth. wrong here, because LO before and MSO now still save it properly, but not being able to reproduce and having the issue on a specific document only will almost certainly hinder solving it indefinitely. I agree with having this bug closed, and the moral here is to test and write all the details while it's fresh, and not to confirm before it's all clear.