Created attachment 171490 [details] chapterNumberingTortureTest6.docx: hand-modified using Heading 4 style This bug report is a follow-up to bug 141964, and depends on its fixes. It has just changed the style names from the other document to now be Heading 3 and Heading 4. In theory it shouldn't really make any difference then, right? Well, it does - in two different aspects. First, I was surprised to see that in Word it makes a difference. There are some default spacing differences - which in this document means that it takes three pages now. Second, LibreOffice assigns special meaning to Heading X styles, and makes a separate numbering style which cannot be shared with other styles or direct formatting. Steps to reproduce: Open the document. - there is no extra before/after spacing added for the Heading/inherited styles. - the initial parts of the numbering are missing for the Heading styles - the non-heading styles have a separate numbering list that starts from "1st".
Created attachment 171491 [details] chapterNumberingTortureTest6.pdf: printed from Word 2003 P.S. In old Word 2003, the body-level numbering still picked up the indenting from the numbering style, but in Word 2016 it doesn't.
Created attachment 171498 [details] chapterNumberingTortureTest7.docx: a related example, adding a test for no numId specified. The rule seems to be: -numId is essential. If it is missing, numbering is off (which makes sense). -listLevel is optional. If it is missing, it means level0 (the first level). -outlineLevel has no impact at all on listLevel or numbering. In this document, Heading 3 (which in LO automatically has the "Outline" numId attached) should not have numbering enabled. Generally LO handles this correctly, I'm happy to see. The only time I see a problem here is with Heading X styles.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/2f9d909a01f90197c3029a446f8aac8135f53f48 tdf#76817 tdf#141966 ooxmlexport: write OutlineRule if not inherited It will be available in 7.2.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.
There are MANY patches in gerrit waiting for LO 7.3 to start.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/3e09e0784ad7669d3e0a7655f5e604a2387b1b5d tdf#141966 writerfilter CN: fix chapter number identification It will be available in 7.3.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.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/e5b3f975144228d49c0bac71031fc7356fd252ab tdf#141966 writerfilter CN: set minimum threshold It will be available in 7.3.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.
Created attachment 175033 [details] Test docx generated by MSO with a simple Heading 1 This document opens fine with master (i.e. the numbering is "I." for heading 1), but does not work on 7.2 branch (i.e. the numbering shows "A."). I reverse bibisect to commit 3e09e0784ad7669d3e0a7655f5e604a2387b1b5d. I hope this fix also be implemented on 7.2. But as Justin has mentioned in that.commit, it is risky?
And maybe we should remove the target:7.2.0 whiteboard flag here?
(In reply to Kevin Suo from comment #7) > I hope this fix also be implemented on 7.2. But as Justin has mentioned in > that.commit, it is risky? Extremely risky. There is absolutely no way that I will stick my neck out and backport any of these commits to 7.2.