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.
Created attachment 118807 [details] How headers look in LO4 Here is how the headers look in LO4
Created attachment 118808 [details] How headers look in LO5 And here is how LO5 displays and treats them
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.
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.
Created attachment 118822 [details] Document with line spacing problem
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)
bibisect-win32-5.0, oldest version contains bug too, git checkout oldest: Version: 4.5.0.0.alpha0+ Build ID: 57d6b92b69a31260dea0d84fcd1fc5866ada7adb
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
Matthew, can you please confirm?
Matthew is there only because he built the bibisect repo :) Suspected comment seems to have been picked from AOO.
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]
CommitDate is Jun 30 2014 but this Apache bug has some more fixes after that date until Jul 08 2014.
*** Bug 89937 has been marked as a duplicate of this bug. ***
Same issue can be also reproduced with attachment 64689 [details]
Created attachment 129099 [details] another document. it displays 1 instead of 1.1
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.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
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+.
*** Bug 104239 has been marked as a duplicate of this bug. ***
*** Bug 129579 has been marked as a duplicate of this bug. ***
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.)
(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.
(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 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;
Created attachment 171248 [details] numbered headers example_reduced.doc: the essense of this bug report.
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
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.
Backporting is off-limits for numbering-related fixes!
(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