Bug 130670 - Fileopen: Numbered lists don't restart after header in DOC (override of abstract definition)
Summary: Fileopen: Numbered lists don't restart after header in DOC (override of abstr...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: filter:doc
: 106063 (view as bug list)
Depends on: 123405
Blocks: DOC-Bullet-Number-Lists
  Show dependency treegraph
 
Reported: 2020-02-14 16:15 UTC by Timur
Modified: 2021-08-21 18:20 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample DOC (78.00 KB, application/msword)
2020-02-14 16:15 UTC, Timur
Details
Sample DOC compared MSO 2013 LO 7.0+ (55.43 KB, image/png)
2020-02-14 16:18 UTC, Timur
Details
download/104239_numbering.pdf: MS Word 2016's rendering of attachment 129675 (288.88 KB, application/pdf)
2021-07-02 06:40 UTC, Justin L
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Timur 2020-02-14 16:15:22 UTC
Created attachment 157874 [details]
Sample DOC

This is DOC bug for fileopen issue fixed for DOCX in bug 129221.
Attached is DOC created from DOCX attachment 157344 [details] in MSO 2013.
There were some improvements from OO but I'll still mark Inherited.
Comment 1 Timur 2020-02-14 16:18:39 UTC
Created attachment 157876 [details]
Sample DOC compared MSO 2013 LO 7.0+
Comment 2 Dieter 2020-02-16 06:04:23 UTC
I confirm it with

Version: 7.0.0.0.alpha0+ (x64)
Build ID: eeb2d19e77d6dc47c68e8ba0920a02cf64a1247b
CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: default; VCL: win; 
Locale: de-DE (de_DE); UI-Language: en-GB
Calc: threaded

in comparison with MS Word 2016.
Comment 3 Xisco Faulí 2020-05-06 08:41:07 UTC
Still reproducible in

Version: 7.0.0.0.alpha0+
Build ID: 1eb6210d678bbb0c875f0f72b...
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded
Comment 4 Justin L 2021-04-21 10:44:32 UTC
Outline level PR3 inherits from PR2 which inherits from PR2. PR2 and PR3 don't define iLFO, so they need to inherit that from the parent style.

*** This bug has been marked as a duplicate of bug 123405 ***
Comment 5 Justin L 2021-06-24 08:26:30 UTC
Reopening, since there is something extra happening with this document.


The important thing to note is that the numbering on the A/B/C/D/E/F paragraphs are all based on DIRECT FORMATTING defining numId 0x1e (LFO 29).  (They are a mix of PR1 and PR2 styles, but that is irrelevant to the numbering).

The sublevel's numbering, however, is defined by the paragraph-style PR2, which is numId 0x1d (LFO 28).  So, somehow those two different numIds are connected to each other. (I assume they share an abstract numId. They have the same lsid value.)

This has nothing to do with Chapter Numbering.

<rgLfo type="LFO" index="28" offset="46529">
<lsid value="0x31a83a73"/>
<clfolvl value="0x0"/>

<rgLfo type="LFO" index="29" offset="46545">
<lsid value="0x31a83a73"/>
<clfolvl value="0x9"/>  #seems to mean the number of redefined levels.

<lfoData type="LFOData" offset="46693">
<cp value="0x18"/>
<todo what="LFOData: clfolvl != 0"/>  #Probably the key to solving this!
</lfoData>


<lstf type="LSTF" index="11" offset="36003" size="28 bytes">
<lsid value="0x31a83a73"/>   #THIS IS THE LIST ID SHARED BY THE TWO LFOs
<tplc value="0x7480cdee"/>
<rgistdPara index="0" value="315"/>
<rgistdPara index="1" value="316"/>
<rgistdPara index="2" value="317"/>
<rgistdPara index="3" value="318"/>
<rgistdPara index="4" value="319"/>
<rgistdPara index="5" value="320"/>
<rgistdPara index="6" value="321"/>
<rgistdPara index="7" value="322"/>
<rgistdPara index="8" value="4095"/>
<fSimpleList value="0x0"/>
<unused1 value="0x0"/>
<fAutoNum value="0x0"/>
<unused2 value="0x0"/>
<fHybrid value="0x0"/>
<reserved1 value="0x0"/>
<grfhic type="grfhic">
<fhicChecked value="0x0"/>
<fhicFormat value="0x0"/>
<fhicListText value="0x0"/>
<fhicPeriod value="0x0"/>
<fhicLeft1 value="0x0"/>
<fhicListTab value="0x0"/>
<unused value="0x0"/>
<fhicBullet value="0x0"/>
</grfhic>
</lstf>
Comment 6 Justin L 2021-06-28 13:16:39 UTC
I have something that is working at http://gerrit.libreoffice.org/c/core/+/118021, but likely it is not good programming.
Comment 7 Justin L 2021-07-02 06:40:40 UTC
Created attachment 173311 [details]
download/104239_numbering.pdf: MS Word 2016's rendering of attachment 129675 [details]

(In reply to Justin L from comment #6)
> I have something at http://gerrit.libreoffice.org/c/core/+/118021

attachment 129675 [details] from bug 104239 comment 2 shows that my patch is inadequate. It is a good counter-check against any potential bug fix, so make sure to test it.
Comment 8 Justin L 2021-07-05 06:44:26 UTC
(In reply to Justin L from comment #7)
> It is a good counter-check, so make sure to test it.
This is now in ww8export3 as testTdf104239_numbering.
Comment 9 Justin L 2021-07-07 12:44:30 UTC
DOCX bug 95848 is probably a very useful resource for this bug.

commit 7992bd73a2307edce96a145e954f8e4c3ab9f57d
Author: Michael Stahl <Michael.Stahl@cib.de>
Date:   Tue Sep 3 13:49:57 2019 +0200
    tdf#95848 writerfilter: DOCX import: fix mapping of w:abstractNum

    The problem is that the bugdoc has multiple w:num numbering definitions
    that refer to the same w:abstractNum abstract numbering definition.
    
    Apparently (and i can't find this documented anywhere) w:abstractNum
    corresponds to a SwList in Writer, i.e. all w:num that refer to the same
    w:abstractNum share the same numbering tree, but they may have different
    numbering properties via w:lvlOverride.
    
    So i think this should be imported as a single SwList per w:abstractNum,
    and every use of w:lvlOverride should create a new SwNumRule, but still
    share the same SwList; the previous situation was a SwNumRule + SwList
    per w:num element.
    
    This implements simply a SwNumRule per w:num (regardless of
    w:lvlOverride) because that was easy; the AbstractListDef class gets a
    member to store the ListId of the created SwList when any of its
    associated w:num / ListDef is used first, and the non-first ones get
    this ListId set to force them into the same SwList.
    
    Unfortunately it turns out the export has the same
    SwNumRule->w:abstractNum problem, which remains to be fixed.
Comment 10 Justin L 2021-08-21 18:20:31 UTC
*** Bug 106063 has been marked as a duplicate of this bug. ***