Bug 40272 - Filesave ODT as DOC: continued instead of restarted numbering (Comment 10 and Comment 16)
Summary: Filesave ODT as DOC: continued instead of restarted numbering (Comment 10 and...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.4.2 release
Hardware: All All
: low minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, filter:doc
Depends on:
Blocks: DOC-Bullet-Number-Lists
  Show dependency treegraph
 
Reported: 2011-08-21 10:58 UTC by Jambunathan K
Modified: 2023-06-14 23:53 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
lists.org (For submitter's reference) (1.25 KB, application/octet-stream)
2011-08-21 10:58 UTC, Jambunathan K
Details
lists.odt (Writer displays this file as expected) (8.37 KB, application/vnd.oasis.opendocument.text)
2011-08-21 11:00 UTC, Jambunathan K
Details
lists.doc (This file's format is inconsistent with that of odt file's) (17.50 KB, application/msword)
2011-08-21 11:02 UTC, Jambunathan K
Details
styles.xml.diff (21.34 KB, text/x-diff)
2011-08-21 11:28 UTC, Jambunathan K
Details
Lists - compared (92.16 KB, image/jpeg)
2018-01-04 13:52 UTC, Timur
Details
Lists - compared ODT DOC DOCX with 6.4+ (128.94 KB, image/jpeg)
2019-09-10 11:16 UTC, Timur
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jambunathan K 2011-08-21 10:58:34 UTC
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)
Comment 1 Jambunathan K 2011-08-21 11:00:40 UTC
Created attachment 50430 [details]
lists.odt (Writer displays this file as expected)
Comment 2 Jambunathan K 2011-08-21 11:02:16 UTC
Created attachment 50431 [details]
lists.doc (This file's format is inconsistent with that of odt file's)
Comment 3 Jambunathan K 2011-08-21 11:12:06 UTC
See this thread 
http://thread.gmane.or/gmane.comp.documentfoundation.libreoffice.devel/14739

Bug is acknowledged by 	Thorsten Behren.
Comment 4 Jambunathan K 2011-08-21 11:28:14 UTC
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>
`----
Comment 5 Jambunathan K 2011-08-21 11:32:24 UTC
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>
`----
Comment 6 Björn Michaelsen 2011-12-23 12:35:56 UTC Comment hidden (obsolete)
Comment 7 Jambunathan K 2012-02-14 09:14:19 UTC
The problem as reported persists in the following version of LibreOffice.

LibreOffice 3.4.5 
OOO340m1 (Build:502)
Comment 8 Samuel Mehrbrodt (allotropia) 2013-12-01 22:24:16 UTC
Confirmed in 4.1.
Comment 9 QA Administrators 2015-04-19 03:21:27 UTC Comment hidden (obsolete)
Comment 10 Gordo 2015-06-13 17:01:15 UTC
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
Comment 11 QA Administrators 2016-09-20 10:02:08 UTC Comment hidden (obsolete)
Comment 12 Timur 2018-01-04 13:52:13 UTC
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.
Comment 13 Timur 2019-09-10 11:16:44 UTC
Created attachment 154076 [details]
Lists - compared ODT DOC DOCX with 6.4+

Repro 6.4+.
Comment 14 Justin L 2020-04-23 19:41:49 UTC Comment hidden (obsolete)
Comment 15 Justin L 2021-07-01 14:09:54 UTC
Not fixed even though bug 120396 is fixed.  Re-opening.  Probably related to bug 130670 then.
Comment 16 Justin L 2021-07-05 05:33:50 UTC
(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.
Comment 17 Timur 2021-07-15 14:32:10 UTC
This remains DOC only bug, DOCX was resolved in 6.4 repo in adceab34ca45128d4848edcc58affa220be87686 by Michael Stahl (no bug number).
Comment 18 Justin L 2023-06-14 23:53:16 UTC
repro 24.2+