Bug 141966 - FILEOPEN DOCX: Outline numbering on Heading X styles not imported well.
Summary: FILEOPEN DOCX: Outline numbering on Heading X styles not imported well.
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium normal
Assignee: Justin L
URL:
Whiteboard: target:7.3.0
Keywords: filter:docx
Depends on: 141964
Blocks: DOCX-Bullet-Number-Outline-Lists 136194
  Show dependency treegraph
 
Reported: 2021-04-29 07:41 UTC by Justin L
Modified: 2021-09-15 12:19 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
chapterNumberingTortureTest6.docx: hand-modified using Heading 4 style (5.99 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2021-04-29 07:41 UTC, Justin L
Details
chapterNumberingTortureTest6.pdf: printed from Word 2003 (17.43 KB, application/pdf)
2021-04-29 07:44 UTC, Justin L
Details
chapterNumberingTortureTest7.docx: a related example, adding a test for no numId specified. (5.88 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2021-04-29 09:30 UTC, Justin L
Details
Test docx generated by MSO with a simple Heading 1 (28.35 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2021-09-15 12:14 UTC, Kevin Suo
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Justin L 2021-04-29 07:41:02 UTC
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".
Comment 1 Justin L 2021-04-29 07:44:39 UTC
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.
Comment 2 Justin L 2021-04-29 09:30:44 UTC
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.
Comment 3 Commit Notification 2021-05-18 14:07:36 UTC
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.
Comment 4 Justin L 2021-05-20 12:19:57 UTC
There are MANY patches in gerrit waiting for LO 7.3 to start.
Comment 5 Commit Notification 2021-07-06 06:53:16 UTC
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.
Comment 6 Commit Notification 2021-07-08 07:01:14 UTC
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.
Comment 7 Kevin Suo 2021-09-15 12:14:05 UTC
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?
Comment 8 Kevin Suo 2021-09-15 12:17:53 UTC Comment hidden (obsolete)
Comment 9 Justin L 2021-09-15 12:18:40 UTC
(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.