Bug 94326 - Chapter numbering (heading styles) not displaying numbering (DOC fileopen)
Summary: Chapter numbering (heading styles) not displaying numbering (DOC fileopen)
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.4.0.3 release
Hardware: All All
: medium normal
Assignee: Justin L
URL:
Whiteboard: target:7.2.0
Keywords: bibisected, bisected, filter:doc, regression
: 89937 (view as bug list)
Depends on:
Blocks: DOC-Bullet-Number-Lists
  Show dependency treegraph
 
Reported: 2015-09-17 19:16 UTC by Andrew Kornilov
Modified: 2021-04-21 11:29 UTC (History)
11 users (show)

See Also:
Crash report or crash signature:


Attachments
Hidden numbering for headers (165.50 KB, application/msword)
2015-09-17 19:16 UTC, Andrew Kornilov
Details
How headers look in LO4 (529.25 KB, image/png)
2015-09-17 19:17 UTC, Andrew Kornilov
Details
How headers look in LO5 (546.74 KB, image/png)
2015-09-17 19:17 UTC, Andrew Kornilov
Details
Document with line spacing problem (383.50 KB, application/msword)
2015-09-18 12:58 UTC, Andrew Kornilov
Details
another document. it displays 1 instead of 1.1 (26.00 KB, application/msword)
2016-11-28 20:40 UTC, Xisco Faulí
Details
5.3.3.2 Error moved (168.75 KB, application/pdf)
2017-06-15 23:11 UTC, Gabriel Bowater
Details
Hidden numbering compared MSO LO (220.89 KB, image/jpeg)
2019-11-14 15:27 UTC, Timur
Details
numbered headers example_reduced.doc: the essense of this bug report. (40.00 KB, application/msword)
2021-04-17 08:03 UTC, Justin L
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Kornilov 2015-09-17 19:16:38 UTC
Created attachment 118806 [details]
Hidden numbering for headers

Hi there,

Just tried 5.0.1 and 5.0.2 RC1 and got a regression with DOC format: numbered headers not displayed.

Please, open the attached file in LO4 and then LO5 and you'll spot the difference: headers do not have numbering.

Furthermore, they are treated as numbering, i can change the style, but when i save, close and open it again, the style is lost and is not shown.

I'e been trying to play with styles (imported with document and default), sometimes LO5 saves the style when it's one of the default ones, but not sure when that happens.  

LO4 works with these styles less or more correct.
LO4 says these headers have WW8Num8 style, while LO5 says it has WW8Num1 style. (see the attached screenshots)

Thank you in advance.
Comment 1 Andrew Kornilov 2015-09-17 19:17:20 UTC Comment hidden (obsolete)
Comment 2 Andrew Kornilov 2015-09-17 19:17:58 UTC Comment hidden (obsolete)
Comment 3 Andrew Kornilov 2015-09-17 19:29:00 UTC
Just tried this:

1. Opened the attached DOC in LO5.
2. Applied the style WW8Num8 to the first heading
3. Saved it as ODT.
4. Opened that ODT in LO5 and everything was OK.
5. Then saved that new ODT file as a new DOC file
6. Opened that new DOC file and that heading missed the numbering again.

So it seems to me something is different when parsing numbering from DOC files.
Comment 4 Andrew Kornilov 2015-09-18 12:57:29 UTC
Hi,

I have three copies (a little bit different) of that document. In one of the copies i can't also save the line spacing value. It's always 105%.  I change it in the style settings, change across text for all paragraphs, save it, open and the spacing is again 105%.

I tried to export to ODT, change line spacing, save it and open again - everything is OK. Then i exported that ODT to DOC and it also had correct line spacing.

Please, check it, i'm attaching the document.
Comment 5 Andrew Kornilov 2015-09-18 12:58:04 UTC
Created attachment 118822 [details]
Document with line spacing problem
Comment 6 Buovjaga 2015-10-01 11:05:29 UTC
Confirmed with attachment 118806 [details]. 4.3.0.1 displays the heading numbers ok, while 5.0.2 loses them.

Win 7 Pro 64-bit, Version: 5.0.2.2 (x64)
Build ID: 37b43f919e4de5eeaca9b9755ed688758a8251fe
Locale: fi-FI (fi_FI)
Comment 7 raal 2015-10-05 05:11:03 UTC
bibisect-win32-5.0, oldest version contains bug too, git checkout oldest: Version: 4.5.0.0.alpha0+
Build ID: 57d6b92b69a31260dea0d84fcd1fc5866ada7adb
Comment 8 raal 2015-11-19 19:19:25 UTC
4b717bca8a28effd41dea7fa15191d6ad271ee5e is the first bad commit
commit 4b717bca8a28effd41dea7fa15191d6ad271ee5e
Author: Matthew Francis <mjay.francis@gmail.com>
Date:   Sat Mar 14 22:22:10 2015 +0800

    source-hash-c99f264be5eaf481f88606e2606c34170675c1b4
    
    commit c99f264be5eaf481f88606e2606c34170675c1b4
    Author:     Oliver-Rainer Wittmann <orw@apache.org>
    AuthorDate: Fri Jun 27 12:34:10 2014 +0000
    Commit:     Caolán McNamara <caolanm@redhat.com>
    CommitDate: Mon Jun 30 09:46:15 2014 +0100
    
        Related: #i78498# improvements/corrections regarding outline level & Co
    
        - import outline level attribute at Paragraph Styles
        - import outline level attribute at paragraphs
        - refactor code to apply list level properties to Outline Style
        -- only consider WW8 list styles applied to WW8 Built-in Heading Styles
        -- only assign our counterparts of WW8 Built-in Heading Styles to Outline Style
    
        (cherry picked from commit 9032e17b9989d4fc8faefe7717d2ea14d124e653)
        (cherry picked from commit c3a35e3885334cb37b2b569daaf536a8cc26031d)
    
        Conflicts:
        	sw/source/filter/rtf/swparrtf.cxx
        	sw/source/filter/ww8/ww8par.cxx
        	sw/source/filter/ww8/ww8par.hxx
        	sw/source/filter/ww8/ww8par2.cxx
        	sw/source/filter/ww8/ww8par2.hxx
        	sw/source/filter/ww8/ww8par3.cxx
        	sw/source/filter/ww8/ww8par5.cxx
        	sw/source/filter/ww8/ww8par6.cxx
        	sw/source/filter/xml/swxml.cxx
    
        Change-Id: Ia70920f91300fa47236533f59356abb546a94fb3

bibisect-44max$ git bisect log
# bad: [cf6ea17155fabb2a120ba07c150735591ac861d7] source-hash-3f94c9e9ddfd807b449f3bb9b232cf2041fa12d2
# good: [fc71ac001f16209654d15ef8c1c4018aa55769f5] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e
git bisect start 'latest' 'oldest'
# bad: [8cf60cc706948588e2f33a6d98b7c55d454e362a] source-hash-f340f0454627939f1830826fb5cc53a90e6c62a4
git bisect bad 8cf60cc706948588e2f33a6d98b7c55d454e362a
# bad: [d9885f526fc7a09cc8f9f8ee643af1b966be24bb] source-hash-d1465c64c6f64ad8dd25e40cdc69649b24b305ea
git bisect bad d9885f526fc7a09cc8f9f8ee643af1b966be24bb
# good: [e3eab511ffbcd2e1e2c67e7a4fec162bb0b26b7a] source-hash-dc9cc46f3223aff3f85d3ce9696178a5f4d3d087
git bisect good e3eab511ffbcd2e1e2c67e7a4fec162bb0b26b7a
# good: [1477f347fb61b5b07de64312247b49371812f5b4] source-hash-4598bbe41d0906a34ceb1126c7fce2108642cd8e
git bisect good 1477f347fb61b5b07de64312247b49371812f5b4
# good: [fdbfc593506d9f38152b80f14c9e7afdbef0b40a] source-hash-6024ddbfac8e62db50dd5352d610c87d279627de
git bisect good fdbfc593506d9f38152b80f14c9e7afdbef0b40a
# good: [b1d1e3e3ac1515cf33be95eba837476142fb6ca8] source-hash-f55ddffd7e81cc8f3314047a6aa62991e2d293b1
git bisect good b1d1e3e3ac1515cf33be95eba837476142fb6ca8
# bad: [163b7bd042acbad89907ad1e16c268229c8468a0] source-hash-e123226d874d59799ba4ca2a8919e50e7eb2ba3b
git bisect bad 163b7bd042acbad89907ad1e16c268229c8468a0
# bad: [4b717bca8a28effd41dea7fa15191d6ad271ee5e] source-hash-c99f264be5eaf481f88606e2606c34170675c1b4
git bisect bad 4b717bca8a28effd41dea7fa15191d6ad271ee5e
# good: [8297925628ef607d65f047e975f795b31643c08e] source-hash-67c20d42b5ca06458b154356877f4ad5952736f4
git bisect good 8297925628ef607d65f047e975f795b31643c08e
# good: [9191d7a142042d0fe7a76d85c2c04fa01d02b544] source-hash-eba630ca1689d65d6f58c0e6bd7658cc6eac8dcc
git bisect good 9191d7a142042d0fe7a76d85c2c04fa01d02b544
# good: [0f8de9580096702299b708f48950eab76e4eb83c] source-hash-fb597ee98f69dd3243c45cb0ff76516f7ec31c73
git bisect good 0f8de9580096702299b708f48950eab76e4eb83c
# good: [9d3979ce59c5c9fa6f0f6a8dedc00bb08660a45c] source-hash-0fef0d41f7e373d562c0689107183ab40e09d129
git bisect good 9d3979ce59c5c9fa6f0f6a8dedc00bb08660a45c
# good: [63d1a075ce19e6cdc9b6311b4f849840defb1d75] source-hash-679b1ed8655c3128e2f14a8d5cdc9be25c822bc0
git bisect good 63d1a075ce19e6cdc9b6311b4f849840defb1d75
# first bad commit: [4b717bca8a28effd41dea7fa15191d6ad271ee5e] source-hash-c99f264be5eaf481f88606e2606c34170675c1b4
Comment 9 Timur 2015-11-27 09:37:44 UTC Comment hidden (obsolete)
Comment 10 Buovjaga 2015-11-27 09:44:01 UTC Comment hidden (obsolete)
Comment 11 Robinson Tryon (qubit) 2015-12-13 11:14:23 UTC Comment hidden (obsolete)
Comment 12 Timur 2016-02-17 08:15:38 UTC
CommitDate is Jun 30 2014 but this Apache bug has some more fixes after that date until Jul 08 2014.
Comment 13 Xisco Faulí 2016-09-23 17:11:23 UTC
*** Bug 89937 has been marked as a duplicate of this bug. ***
Comment 14 Xisco Faulí 2016-11-18 19:20:11 UTC
Same issue can be also reproduced with attachment 64689 [details]
Comment 15 Xisco Faulí 2016-11-28 20:40:22 UTC
Created attachment 129099 [details]
another document. it displays 1 instead of 1.1
Comment 16 Gabriel Bowater 2017-06-15 23:11:12 UTC
Created attachment 134051 [details]
5.3.3.2 Error moved

Opening in LO 5.3.3.2 error doesn't manifest on first page but still occurs on third page with the header number not appearing for what should be Section 3. Also, the numbering for the numbered paragraphs in the section is out of sequence.
Comment 17 QA Administrators 2018-11-06 03:57:08 UTC Comment hidden (obsolete)
Comment 18 Timur 2019-11-14 15:27:13 UTC
Created attachment 155821 [details]
Hidden numbering compared MSO LO

Number was seen in LO 4.2 (and as explained in 4.3) and still not in LO 6.5+.
Comment 19 Timur 2019-12-20 20:05:26 UTC Comment hidden (obsolete)
Comment 20 Xisco Faulí 2019-12-27 16:28:45 UTC Comment hidden (obsolete)
Comment 21 Justin L 2021-04-15 06:21:55 UTC
Is this a clue? I used Word 2003 to round-trip the file as DOCX, and Heading1 doesn't have an ilvl value.
<w:numPr>
  <w:numId w:val="2"/>
</w:numPr>

(In the DOCX, the numbering/level is direct assigned to the paragraph - perhaps done by the round-tripping? Using a new version of Word to RT might be better.)
Comment 22 Justin L 2021-04-16 07:17:40 UTC
(In reply to Timur from comment #19)
> *** Bug 104239 has been marked as a duplicate of this bug. ***

This one looks like a different problem than the others - an inheritance problem. It inherits from Heading 2. So in Word it would be at level 2, but in Writer, there is no level inheritance from "Chapter Numbering" styles - so in this case a  special effort would need to be made to copy the OutlineLvl setting from the parent style, I think.
Comment 23 Justin L 2021-04-16 11:05:24 UTC
(In reply to Timur from comment #19)
> *** Bug 104239 has been marked as a duplicate of this bug. ***
Oops - I mixed the two up. This one is the real comment 19 test_numerotation.doc.

In this one, Titre 1 (heading 1) really does not specify a numbering list (sprmPIlfo) or a listlevel (sprmPIlvl), only an outline level (sprmPOutLvl). So there is no numbering associated with this style.
Instead, the numbering is applied directly on all four paragraphs using sprmPIlfo listId 1.

Titre 2 specifies outlineLevel 1(aka 2), ListLevel 1 (aka 2), and listId 1 (same as the heading1 paragraphs).

That causes a problem, because LO uses a secret, internal list for Chapter Numbering (Heading 2-10) which is not available for Direct Properties. (I think there is a way for numbering styles to share a list - which is how this would have to play out.)
Comment 24 Justin L 2021-04-16 17:56:52 UTC
comment 0's "numbered headers example.doc" is different again.

In this one, Заголовок 1 is Heading 1, and it defines outlinelvl=0, ilvl=0 (twice) and ilfo numId as 1 and then 2.
<rgtchar value="Heading 8"/>
<istd value="0x8"/>
<sprm value="0x2640" ispmd="0x40" fSpec="0x1" sgc="paragraph" spra="1" name="sprmPOutLvl" operandSize="1" operand="0x7"/>
<sprm value="0x260a" ispmd="0xa" fSpec="0x1" sgc="paragraph" spra="1" name="sprmPIlvl" operandSize="1" operand="0x7"/>
<sprm value="0x460b" ispmd="0xb" fSpec="0x1" sgc="paragraph" spra="2" name="sprmPIlfo" operandSize="2" operand="0x1"/>
<sprm value="0x260a" ispmd="0xa" fSpec="0x1" sgc="paragraph" spra="1" name="sprmPIlvl" operandSize="1" operand="0x7"/>
sprm value="0x460b" ispmd="0xb" fSpec="0x1" sgc="paragraph" spra="2" name="sprmPIlfo" operandSize="2" operand="0x2"/>

In addition, the paragraph seems to have direct formatting setting ilvl to 0, ilfo to 8.
<transformed value="ОБЩИЕ ПОЛОЖЕНИЯ\x0D"/>
<bxPap type="BxPap" offset="3149" size="4608 bytes">
<istd value="0x1"/>  #paragraph style #1 - aka heading 1
<sprm value="0x260a" ispmd="0xa" fSpec="0x1" sgc="paragraph" spra="1" name="sprmPIlvl" operandSize="1" operand="0x0"/>
<sprm value="0x460b" ispmd="0xb" fSpec="0x1" sgc="paragraph" spra="2" name="sprmPIlfo" operandSize="2" operand="0x8"/>  #numId eight

But apparently the numbering style is set to NONE(instead of decimal, romanLower, letterUpper etc) for the numbering list 2 (aka Heading 1). So that part is all correct.
<lvl type="LVL" index="1" offset="14147">   #numID=2
<lvlf type="LVLF" offset="14147">
<iStartAt value="0x1"/>
<nfc value="0xff"/>  #if nfc is equal to 0xFF or 0x17, this level has no number sequence, and the level number of the paragraph is an empty string.

The numbering style for numId 8 (LVL 63-71) specifies decimal numbering.
<lvl type="LVL" index="63" offset="17904">
<lvlf type="LVLF" offset="17904">
<iStartAt value="0x1"/>
<nfc value="0x0"/>  #decimal


It seems as if the direct formatting is being removed, because the numbering can be controlled by changing the Chapter Numbering number type.

This is "fixed" by commenting out //bAppliedChangedOutlineStyle = true;
Comment 25 Justin L 2021-04-17 08:03:07 UTC
Created attachment 171248 [details]
numbered headers example_reduced.doc: the essense of this bug report.
Comment 26 Justin L 2021-04-19 15:48:27 UTC
The problem is in RegisterNumFormatOnTextNode
    if (bSetAttr && pTextNd->GetNumRule() != pRule
        && pTextNd->GetNumRule() != m_rDoc.GetOutlineNumRule())
Well, the textnode has been assigned the outlinenumrule, so this is skipped. Basically, it means that you can't override a heading style's numrule.

What needs to happen is to capture the original DOC numrule (in this case numId 2) and compare it to the one being assigned (in this case numId 8).

Proposed fix at http://gerrit.libreoffice.org/c/core/+/114298
Comment 27 Commit Notification 2021-04-21 06:52:00 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/3c230b0a440ab4d434c4ddabd6959fb1654b6eff

tdf#94326 doc import: allow direct numbering to cancel outlineStyle

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 28 Justin L 2021-04-21 08:41:06 UTC
Backporting is off-limits for numbering-related fixes!
Comment 29 Buovjaga 2021-04-21 11:29:02 UTC
(In reply to Justin L from comment #25)
> Created attachment 171248 [details]
> numbered headers example_reduced.doc: the essense of this bug report.

I confirm ОБЩИЕ ПОЛОЖЕНИЯ now has 1. numbering

Arch Linux 64-bit
Version: 7.2.0.0.alpha0+ / LibreOffice Community
Build ID: b82f39f29a9ceeacb06ae9d1571665327d3e3019
CPU threads: 8; OS: Linux 5.11; UI render: default; VCL: kf5 (cairo+xcb)
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
Calc: threaded
Built on 21 April 2021