Bug 95848 - FORMATTING: Numbering list in DOCX does not continue previous numbering
Summary: FORMATTING: Numbering list in DOCX does not continue previous numbering
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.6.0.4 release
Hardware: Other All
: high normal
Assignee: Michael Stahl (allotropia)
URL:
Whiteboard: target:6.4.0
Keywords: filter:docx
: 50774 94819 102264 108557 (view as bug list)
Depends on:
Blocks: DOCX-Bullet-Number-Outline-Lists
  Show dependency treegraph
 
Reported: 2015-11-16 09:58 UTC by Aleksey Alekseev
Modified: 2021-01-26 19:27 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:


Attachments
DOCX file (123.04 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2015-11-16 09:58 UTC, Aleksey Alekseev
Details
MS Word screenshot (68.23 KB, image/png)
2015-11-16 09:59 UTC, Aleksey Alekseev
Details
LO Writer screenshot (56.55 KB, image/png)
2015-11-16 09:59 UTC, Aleksey Alekseev
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Aleksey Alekseev 2015-11-16 09:58:00 UTC
Created attachment 120570 [details]
DOCX file

Attached DOCX file created using MS Office Word.
It contains numeration list:
1.1.1 A
1.1.2 B
1.1.3 C
But LibreOffice Writer display it wrong:
1.1.1 A
1.1.2 B
1.1.1 C

LibreOffice version: 5.0.3.2
MS Office version: 14.0.6129.5000
Comment 1 Aleksey Alekseev 2015-11-16 09:59:03 UTC
Created attachment 120571 [details]
MS Word screenshot
Comment 2 Aleksey Alekseev 2015-11-16 09:59:36 UTC
Created attachment 120572 [details]
LO Writer screenshot
Comment 3 Timur 2015-11-16 10:52:48 UTC
Current behavior from 3.6. It was worse before.
Comment 4 Timur 2016-08-02 16:07:54 UTC
This may be related to Bug 94819 or maybe Bug 76817 or even Bug 50774. 

<w:p w:rsidR="00B8717E" w:rsidRPr="00B03AA7" w:rsidRDefault="00184B0E" w:rsidP="00C367F5">
<w:t>A</w:t>
<w:p w:rsidR="00B8717E" w:rsidRPr="00B03AA7" w:rsidRDefault="00184B0E" w:rsidP="00C367F5">
<w:t>B</w:t>
<w:p w:rsidR="008D18EC" w:rsidRPr="00641F6C" w:rsidRDefault="00184B0E" w:rsidP="00184B0E">
<w:t>C</w:t>

https://blogs.msdn.microsoft.com/brian_jones/2006/12/11/whats-up-with-all-those-rsids/
w:rsid XML tags are inserted in the document file when Track Changes is turned on, or when you use the Compare Documents feature.

LO doesn't read that well, but it's easy to say: continue previous numbering.
Comment 5 Justin L 2018-02-13 05:55:36 UTC Comment hidden (obsolete)
Comment 6 Justin L 2018-02-13 06:05:02 UTC
The key to fixing this will be to pruning out identical list styles. In this case, both style1 and style6 both use abstract style 24 with no modifications.

<w:num w:numId="1">
   <w:abstractNumId w:val="24"/>
</w:num>

<w:num w:numId="6">
   <w:abstractNumId w:val="24"/>
</w:num>

<w:pPr>
   <w:pStyle w:val="-3"/>  #para style Пункт-3 using list numId=6 ilvl=2
</w:pPr>
<w:r>
   <w:t>B</w:t>
</w:r>

<w:pPr>
   <w:pStyle w:val="-3"/>
   <w:numPr>
      <w:ilvl w:val="2"/>
      <w:numId w:val="1"/>
   </w:numPr>
</w:pPr>
<w:r>
   w:t>C</w:t>
</w:r>
Comment 7 QA Administrators 2019-02-14 03:49:38 UTC Comment hidden (obsolete)
Comment 8 Michael Stahl (allotropia) 2019-08-30 15:16:22 UTC
so it looks like a "list" in Word is defined by a w:abstractNum instance and everything derived from it via w:num is part of the list?

i don't find that documented anywhere, but i just read the OOXML numbering stuff for the first time, but this is consistent with a couple documents i made in Word 2013.

hmmm comment #6 has a relatively easy to implement fix for this document, but in general a w:num can contain a w:lvlOverride which would require a numbering style in writer's model.

perhaps the w:lvlOverride properties could all be set on the paragraph itself where it's applied, but that doesn't appear to be ideal.

but it looks like SwList can actually hold arbitrary SwTextNodes - while it does have a "default" list style, you can manually set ListId property on any SwTextNode to add it to a SwList.

i'll try to get DomainMapper to do that...
Comment 9 Commit Notification 2019-09-04 08:41:32 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/+/7992bd73a2307edce96a145e954f8e4c3ab9f57d%5E%21

tdf#95848 writerfilter: DOCX import: fix mapping of w:abstractNum

It will be available in 6.4.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 10 Commit Notification 2019-09-05 08:19:00 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/+/1f6b7030cbdc81e8e408e3a13bfcd01fcbdd7550%5E%21

tdf#95848 sw: DOCX export: crude implementation of abstractNum mapping

It will be available in 6.4.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 11 Commit Notification 2019-09-05 10:47:25 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/+/632ee9aae6d5f3cf08b6d6b2789310c20db713b7%5E%21

tdf#95848 sw: DOCX export: export w:lvlOverride elements

It will be available in 6.4.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 12 Michael Stahl (allotropia) 2019-09-05 11:31:34 UTC
fixed on master; also fixed the export

somewhere in the ECMA spec i find this which could be read as implying that a numbering definition corresponds to a "list" / "number tree" ... but the attached document is evidence that this isn't the case; the hypothesis that an abstract numbering definition corresponds to a list is more likely.

"The numbering at any particular numbering level is restarted when a paragraph in the current document
from the same numbering definition uses the level specified in the lvlRestart element for this
numbering level."
Comment 13 Timur 2019-09-06 08:21:42 UTC
*** Bug 94819 has been marked as a duplicate of this bug. ***
Comment 14 Timur 2019-09-06 08:28:38 UTC
*** Bug 50774 has been marked as a duplicate of this bug. ***
Comment 15 Timur 2019-09-06 10:08:34 UTC
*** Bug 102264 has been marked as a duplicate of this bug. ***
Comment 16 Timur 2019-09-06 12:24:30 UTC
Michael, kudos for your work. 
You deserved an all-included visit to Spain for this one :)
I hope I'm right with those duplicates.
Comment 17 Gabor Kelemen (allotropia) 2019-09-08 21:35:16 UTC
*** Bug 108557 has been marked as a duplicate of this bug. ***
Comment 18 Timur 2019-09-10 10:13:52 UTC
Another one fixed is attachment 152672 [details], wrongly attached in Bug 51168.
Comment 19 Timur 2020-05-06 15:52:51 UTC
This one also fixed attachment 119772 [details] from Bug 95189, but it regressed later so bug is still open.