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.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.