Created attachment 102755 [details] Example file - save it to DOC for got described results When I working with numbering list and try to individually format some items, all works well if I saving to ODT format. But when I save to DOC (MS Word) format, all list is formatted with only one individual style, so all other styles are lost. How to reproduce: 1. Create new LibreOffice Writer document. 2. Create numbering list in it: --- 1. Item 1 2. Item 2 3. Item 3 4. Item 4 --- 3. Select via mouse text from start of text "Item 2" to end of "Item 3" (screenshot http://i.imgur.com/zelOsvx.png ) and apply bold style (Ctrl+B) - you will got list with "2." and "3." numbers via Bold style, but "1." and "4." without Bold (screenshot http://i.imgur.com/AKbKrS6.png) 4. Save this document as ODT, close and open again - all styles here without changes (this file is attached to issue). 5. Save this document as DOC, close and open again - you will see that all list numbers goes Bold - screenshot http://i.imgur.com/RE5NSTr.png But Bold must be only 2 and 3 items. Same problem with Italic formatting and other formatting too. So custom item styles is applied to all items in list when exporting to MS Office DOC format. --- Described howto is only example how to reproduce, when working with styling and numbering list - this bug is very annoying, because it broke all document styles in lists. After investigating this issue I see that LibreOffice creates styles like WW8Num1z0 WW8Num1z1 ... WW8Num1z8 WW8Num2z0 WW8Num2z1 ... WW8Num2z8 and your list will be formatted via only one WW8Num1z0 style. --- Is this issue reproducible on other users? Can we fix it?
Created attachment 102756 [details] Example file that already saved to DOC
Created attachment 102757 [details] Next example with 2 styled lists (in ODT format, save it to DOC) Here is another example that demonstrates the problem with 2 numbered lists - screenshot is here http://i.imgur.com/dtvimOY.png
The formatting of list items in DOC file appears shifted by 1 item backwards in Word.
(In reply to comment #0) > When I working with numbering list and try to individually format some > items, all works well if I saving to ODT format. > > But when I save to DOC (MS Word) format, all list is formatted with only one > individual style, so all other styles are lost. > After investigating this issue I see that LibreOffice creates styles like > WW8Num1z0 WW8Num1z1 ... WW8Num1z8 > > and your list will be formatted via only one WW8Num1z0 style. This is because the MS Binary / OOXML formats do not support named list styles (these are defined in ODF only). Refer this thread for further detail: http://ask.libreoffice.org/en/question/36453/why-are-my-list-styles-renamed-as-wwnumn-when-converting-from-odt-to-docx/ There is nothing LO can do about this. I think this bug can be RESOLVED as NOTABUG.
Owen Genat, thanks for the info, very useful. As I understand, main problem is "OOXML doesn't support named numberings", so this issue can not be fully solved, but list of related problems can be minimized. Main and very annoying problem is when user mark only one item of long list as bold/italic in ODT, in DOC file we got all list styled with this one item style. So if I use list with 100 items, and mark item 91 as bold, in DOC I will see all list with bold style, this is the main problem. Losting style of item #91 is not so serious problem. If we cannot store style info for separate item, why we style all list via style of separate item? Can we cleanup all custom styles of items in list and use defaul style (or first item style) for all list when exporting to DOC? This way will considerably decrease described problem and minimize visible differences in odt and doc file.
(In reply to comment #5) > Main and very annoying problem is when user mark only one item of long list > as bold/italic in ODT, in DOC file we got all list styled with this one item > style. Thanks for clarifying the issue. One thing to note is that the provide ODT examples do not use list styles e.g., ListN or NumberingN. The WWNumN list styles appear to be created by the DOC export filter according to the formatting of the identifier, rather than the list item. Attachment 102755 [details] only has bold and regular identifiers, thus WWNum1 (bold) is created when saving that attachment to DOC format. The result however is that all list items end up with bold identifiers and thus use the WWNum1 list style. In attachment 102757 [details] there are bold, italic, and regular identifiers and again, saving this file to DOC results in three list styles. The styles however in the DOC appear to be WWNum2 (bold+italic), and WWNum3 (Bold) in keeping with the resultant identifier appearance. This explains why, when one of these WWNumN styles is subsequently modified, it affects numerous list items. Exactly why there is a difference between identifier display and apparent definition in the ODT and that in the DOC is unclear. I must admit however that I find list style definitions in DOC/DOCX difficult to determine so this bug really needs a developer to assess it and see what (if anything) is feasible. This report is therefore not so much about the naming of the WWNumN list styles as it is about how list styles of this type (name) are defined / translated when saving to DOC. I am therefore going to confirm this. Status set to NEW. Summary edited for clarity. Apologies for any initial misunderstanding of the issue.
** Please read this message in its entirety before responding ** 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 on a currently supported version of LibreOffice (5.0.0.5 or later) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) http://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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-09-03
The bug is still here on Libreoffice Version: 5.0.0.3.
** Please read this message in its entirety before responding ** 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 on a currently supported version of LibreOffice (5.2.5 or 5.3.0 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) http://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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170306
Dear Murz, 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 159205 [details] Example DOC compared LO MSO As seen, saved DOC number formats are OK when reopen in LO 7.0+ but not in MSO. DOCX is fine.
This sounds like it will get fixed in LO 7.3 with bug 108518's patch.
(In reply to Murz from comment #0) > 5. Save this document as DOC, close and open again - you will see that all > list numbers goes Bold - screenshot http://i.imgur.com/RE5NSTr.png This part is fixed in 7.3. Since this is the essence of the bug report, I'll mark it as fixed.