Created attachment 157874 [details]
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.
Created attachment 157876 [details]
Sample DOC compared MSO 2013 LO 7.0+
I confirm it with
Version: 22.214.171.124.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
in comparison with MS Word 2016.
Still reproducible in
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
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 ***
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">
<rgLfo type="LFO" index="29" offset="46545">
<clfolvl value="0x9"/> #seems to mean the number of redefined levels.
<lfoData type="LFOData" offset="46693">
<todo what="LFOData: clfolvl != 0"/> #Probably the key to solving this!
<lstf type="LSTF" index="11" offset="36003" size="28 bytes">
<lsid value="0x31a83a73"/> #THIS IS THE LIST ID SHARED BY THE TWO LFOs
<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"/>
I have something that is working at http://gerrit.libreoffice.org/c/core/+/118021, but likely it is not good programming.
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.
(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.
DOCX bug 95848 is probably a very useful resource for this bug.
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.
*** Bug 106063 has been marked as a duplicate of this bug. ***