Created attachment 50429 [details] lists.org (For submitter's reference) I am a developer adding support for generating OpenDocument Text files from within Emacs/Orgmode [1]. My exporter generates the odt files by dumping xml directly to the various xml files (i.e, it doesn't rely on any API as such) I am running in to an issue while converting from odt to Microsoft Word 97 format. The problem is that some sections of the odt file are differently formatted in word document. I am attaching three files. 1. lists.org - A text file in Orgmode format. I am attaching this mostly for my own future reference. (Bug description can be seen here) 2. lists.odt - This file is generated by my own org->odt exporter. The bug description (which is seen only with doc file) can be seen in bold. 3. lists.doc - This file is generated by doing File->Save As->Microsoft Word 97/2000/XP(.doc). The description of the bug can be seen in bold while opening this file. IMPORTANT NOTE: It is important that you close the doc file and re-open it all over again within LibreOffice to see the problem behviour. If someone confirms this as a bug I will file a formal bug report. I would also appreciate if a temporary workaround is provided in the meanwhile. (I would prefer workaronds that don't rely on automatic styles much) (Please CC me. I am not subscirbed to this list.) Thanks for your help, Jambunathan K. Footnotes: [1] Orgmode defines a structured markup for text files (very similar to markdown or rst)
Created attachment 50430 [details] lists.odt (Writer displays this file as expected)
Created attachment 50431 [details] lists.doc (This file's format is inconsistent with that of odt file's)
See this thread http://thread.gmane.or/gmane.comp.documentfoundation.libreoffice.devel/14739 Bug is acknowledged by Thorsten Behren.
Created attachment 50433 [details] styles.xml.diff I had to modify the styles.xml file in the odt file as seen in the attached styles.xml.diff. If you look at the OrgNumberedList style you will see that the <style:list-level-properties text:list-level-position-and-space-mode="label-alignment"> is removed and replaced with <style:list-level-properties text:space-before="0.635cm" text:min-label-width="0.635cm"/> Also note that the attribute - text:list-level-position-and-space-mode - is introduced in odf-1.2 spec. ,---- | <text:list-style style:name="OrgNumberedList"> | <text:list-level-style-number text:level="1" style:num-suffix="." style:num-format="1"> | - <style:list-level-properties text:list-level-position-and-space-mode="label-alignment"> | - <style:list-level-label-alignment text:label-followed-by="listtab" text:list-tab-stop-position="1.27cm" fo:text-indent="-0.635cm" fo:margin-left="1.27cm"/> | - </style:list-level-properties> | + <style:list-level-properties text:space-before="0.635cm" text:min-label-width="0.635cm"/> | </text:list-level-style-number> `----
Replacing 1.2 style with 1.1 style still doesn't solve the "Continuation of Numbering" seen with the numbered list. To fix this issue, I had to resort to emitting an explicit text:continue-numbering="false" attribute while generating the top level list. See below for what I mean. ,---- | <text:list text:continue-numbering="false" text:style-name="OrgNumberedList"> | | <text:list-item> | | <text:p text:style-name="Text_20_body"> | L1N1: <text:span text:style-name="Bold">BUG?: In the odt file, numbering of this item rightly starts at 1. In the converted doc file, the numbering continues. The list style clearly states that the numbering for this level should start at 1</text:span>. | | </text:p> | | <text:list text:style-name="OrgNumberedList"> | | <text:list-item> | | <text:p text:style-name="Text_20_body"> | L2N2 | | </text:p> | | </text:list-item> `----
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
The problem as reported persists in the following version of LibreOffice. LibreOffice 3.4.5 OOO340m1 (Build:502)
Confirmed in 4.1.
** 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 (4.4.1 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-04-18
I opened up the odt file and turned Restart Numbering on for the item after the heading “A Complex List” and saved as a doc. The doc file then displayed the numbering correctly after reloading. The Restart Numbering has to be there for the filter when converting so I do not think that is a bug. I created a new text document and turned on Numbering and created different levels. On one of the levels I placed the cursor before the text and backspaced to clear the number. I then saved it as a doc and reloaded the document. The Numbering icon was off and indentation was missing. I repeated this test and saved it as a docx and got the same result. The numbering (formatting, not the number) and indentation is not lost when saved as odt. Windows Vista 64 Version: 4.4.3.2 Build ID: 88805f81e9fe61362df02b9941de8e38a9b5fd16
** 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.1.5 or 5.2.1 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-20160920
Created attachment 138874 [details] Lists - compared If I understand this bug, there were 2 issues when ODT is saved as DOC: - LIN1 numbering is 4 instead of 1 - still repro in 61+ - L3N3 text: paragraph level wrong - not repro anymore This bug could stay open for the first issue or closed for the third.
Created attachment 154076 [details] Lists - compared ODT DOC DOCX with 6.4+ Repro 6.4+.
I'm going to mark this one as a duplicate of a very simply stated version of this bug. Reading this one made my head spin. *** This bug has been marked as a duplicate of bug 120396 ***
Not fixed even though bug 120396 is fixed. Re-opening. Probably related to bug 130670 then.
(In reply to Timur from comment #12) > - LIN1 numbering is 4 instead of 1 - still repro in 61+ I don't see anywhere in the UI that indicates that this should be a numbering restart. So despite the fact that these two lists use the same numbering style, they must actually be different lists - although nothing in the ODT seems to suggest that either, except that one list ends and the next one starts. There are no list-id's in this document, but any modification of the numbering adds them in. (Of course, the list-id's don't make sense to me, because different list-id's can be used for the same "continued numbering list". I'm not going to touch this, because it would require immense understanding of how SW handles lists under the hood.
This remains DOC only bug, DOCX was resolved in 6.4 repo in adceab34ca45128d4848edcc58affa220be87686 by Michael Stahl (no bug number).
repro 24.2+