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.
Created attachment 157876 [details] Sample DOC compared MSO 2013 LO 7.0+
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.
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
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"> <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>
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. 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.
*** Bug 106063 has been marked as a duplicate of this bug. ***
repro 24.2+ The first level A/B/C looks good, but the second level keeps incrementing instead of restarting after A/B/C.