Description: Heading numbering gets messed up - cannot understand why. appears to be same in version 7.3 Steps to Reproduce: 1.created document with headings 2. 3. Actual Results: headings are not consistent when reopening document Expected Results: should be as per design Reproducible: Always User Profile Reset: No Additional Info: [Information automatically included from LibreOffice] Locale: en-US Module: TextDocument [Information guessed from browser] OS: Linux (All) OS is 64bit: yes
Created attachment 193170 [details] ToC before re-opening document I cannot tell if something is messed up in the styles or something else, I then correct every heading (I do this back-spacing the heading to the prev paragraph, then hit Enter, then apply the correct style, and Tab to set it to the right level Insert or re-do the ToC it is correct. Next time I open the doc, the headings are all messed up I cannot figure out what I have done wrong.
I don't see how the headings are "messed up" in the sample document. Can you please clarify exactly what the issue is, using one heading as an example? Thank you. Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 39663a323c3330c18b610fcdc9e9c75ddac770f1 CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: CL threaded
Created attachment 193173 [details] updated ToC screenshot
Look at the full document the ToC was as I saved the document. When I re-opened the document the headings were messed up (see e.g. Person (which should be 1.3 but is now 1.1 Then look at the others. I then Update the ToC Now the ToC is the same as the document headings themselves, but makes no sense see the Screenshot I added
Created attachment 193174 [details] template used for headings I have included the template used for the document.
Reproduced with that "Person" heading, fixing it as Elmar described, then saving and reloading: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 39663a323c3330c18b610fcdc9e9c75ddac770f1 CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: CL threaded Also in 7.5.9, but not in 7.4.0.3 -> regression.
Bibisected with linux-64-7.5 to first bad build [d661924617cc7224d87e7496faf034f095af2c27] which points to de8c8cea231a42a8e4fa9048606de1c41aae0821 which is a cherrypick of: commit 82bbf63582bdf28e7918e58ebf6657a9144bc9f3 author Mike Kaganski Tue Jun 13 23:15:08 2023 +0300 committer Mike Kaganski Wed Jun 14 15:46:53 2023 +0200 tdf#155823: Improve the check if the list id is not required Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153044 Mike, can you please have a look? My steps: 1. Open attachment 193170 [details] 2. Go to heading "1.1 Person" (can update TOC then Ctrl + click it) 3. Remove preceding paragraph break, press enter, Ctrl + 2 to restore heading numbered "1.3" 4. Save and reload, check if numbering persists
I hope this will not be too long to resolve. My work around is to use plain "Headings", then if I need to publish with a ToC, I will replace them with the different levels. But it would be nice if it was not necessary to do that. Of course if the problem persists in v7.3 then that impacts many more people.
Created attachment 193780 [details] A minimal reproducer for tdf#160253 This is a minimized FODT. It revealed that there is an interaction between several things there, namely, the outline / chapter / heading numbering, a numbering in the endnote, and - what's most odd - a numbering attached to the Heading style (the style that is the parent of all actual heading styles; and which normally doesn't need a numbering itself). Without the last piece, everything looks normal. Additionally (a separate issue), there's something wrong in FODT export. Simply re-saving the FODT as FODT will ruin the numbering. So to see the original issue, the attachment needs to be saved as ODT.
From https://bz.apache.org/ooo/show_bug.cgi?id=69627 : > according to the OpenDocument file format specification the first paragraph > has to apply the list style "Numbering 1". A heading only applies the outline > style, if its paragraph's style doesn't define any list style. The paragraph > style of the first paragraph is "Heading 1" and this paragraph style inherits > the list style "Numbering 1" from its parent paragraph style "Heading".
Related commit: 91a5e549cf8750a6342cbdd245170d0de4896604
The problem seems to be on the *initial* import side (at least partially), since, according to the quote (comment 10), the headings in the minimized document (attachment 193780 [details]) must be initially imported with "Numbering 1" list style, not with Outline. Editing that numbering style must immediately reflect in the paragraph formatting; that style must be reported in XMLTextParagraphExport::exportListChange in rPrevInfo / rNextInfo (xmloff/source/text/txtparae.cxx).
Respective quote from the ODF standard: Version 1.3. Part 3, section 16.36 <text:outline-style> [1] > An outline style is a list style that is applied to all headings within a text > document where the heading's paragraph style does not define a list style to use > itself. However, I likely misunderstood this in comment 12. The "if its paragraph's style doesn't define any list style" likely doesn't apply to our case, where the Chapter Numbering feature, which assigns the outline levels to paragraph styles, results in Heading 1 paragraph style to define "Outline" list style explicitly in its style:list-style-name attribute. The "if its paragraph's style doesn't define any list style" is applicable to this case: neither Heading 1, nor the styles it inherits from, define any list-style-name (and possibly, no default-outline-level?). The headings (text:h) have explicit text:outline-level set. In this case, the Outline list style is applied automatically. [1] https://docs.oasis-open.org/office/OpenDocument/v1.3/OpenDocument-v1.3-part3-schema.html#a_16_36__text_outline-style_
Created attachment 193796 [details] A better minimal reproducer without outline numbering This attachment has a normal numbering, with a "numbered" paragraph in endnote; it shows the same problem. So, when the current list needs to restart: * If there is no intermediate endnote with a numbered paragraph, the continuing list has simply text:continue-numbering="true"; * With the intermediate endnote with a numbered paragraph, it has text:continue-list="list933972954". In both cases, the original list has no xml:id attribute (because the endnote numbered paragraph is in another sub-document, and its node is numbered separately from the main body paragraphs - checked in ShouldSkipListId); but it is important (using text:continue-numbering="true" instead of text:continue-list="list1" in the attached document breaks the numbering).
A way forward seems to be collecting the order of list ids in XMLTextParagraphExport::exportTextContentEnumeration (in the initial pass, when bAutoStyles is true); and then using them in the second pass - instead of the current approach of ShouldSkipListId, which constructs DocumentListNodes, asking the document for the nodes in lists, sorting them by the ids, and then checking according to the id order - which is obviously wrong here, where a node with a higher id (main body) is followed by a node with a lower id (endnote), and then goes another higher node id (main body).
https://gerrit.libreoffice.org/c/core/+/166572
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/69ed893087f89d176a5ec4b263ce8d75774be72b tdf#160253: fix list identifier export decision code It will be available in 24.8.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.
Thanks Mike for having a close look at it. Fix verified for steps in comment 7 in: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: d4f6534e8870e8f271984c37ce54a6878f372ae1 CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: CL threaded
The original problem was resolved but this (may have) created a new one.
Created attachment 193872 [details] showing incorrect Level 7 onwards The level of headings up to L6 is as should be, But from L7 not
Sorry! Please see latest attachments
Created attachment 193873 [details] new doc
Created attachment 193874 [details] showing what the settings should be
(In reply to Elmar from comment #19) > The original problem was resolved At which point, you don't reopen the fixed bug, but file a new one.