Description: The Title is pretty self-explanatory but the gist is that. Assume I have generated a bunch of chapter headers, sub headers and so on. I'm using chapter numbering to number these. I use a prefix like "Chapter" for my level 1 outlines. Use something like "Subchapter" for level 2 and so on. When each chapter line is generated, if they are left empty (like It has generated "Chapter 2:") and you go to the next line, then the ToC will not respect these while generating. Currently you have to manually go the each chapter number generated, and type some spaces for ToC to recognize it. It's also very weird because the Navigator component can see all your chapters with ease. Steps to Reproduce: 1.Create chapter numbering schemes with a specified prefix 2.Leave them empty (don't type anything infront of them) 3.Create a ToC. Actual Results: It creates an empty ToC. Expected Results: It should not create an empty ToC. Reproducible: Always User Profile Reset: Yes OpenGL enabled: Yes Additional Info: Version: 7.1.2.2 / LibreOffice Community Build ID: 10(Build:2) CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: kf5 Locale: en-US (en_US.UTF-8); UI: en-US Ubuntu package version: 1:7.1.2~rc2-0ubuntu0.20.04.1~lo3 Calc: threaded
repro 7.2+, and already happened in bibisect43all at LO 3.5. Assume inherited. It seems to me like this is a feature. If there are outline items with no content, then I could easily see why they would be undesirable in a TOC. Otherwise a lot of empty lines could show up in the TOC.
Created attachment 171553 [details] 141925_emptyParaTocEntries.odt: custom style auto-creates Chapter heading P.S. This has nothing to do directly with chapter numbering. Any style specifying an outline level and containing numbering can demonstrate the suggestion.
Created attachment 171554 [details] 141925_emptyParaTocEntriesB.odt: a counter-example Insert a TOC in this document, and it will simulate what could happen to documents if OP's suggestion is followed. There are some compatibility issues at stake here as well. My take on the issue is that you design your documents based on what the program provides. Rarely would chapter numbering be so fluid that it requires numbering to handle it. Rarely are empty numberings deployed. (In fact, pressing "Enter" after one of these REMOVES it.) Based on the difficulty in actually implementing empty-paragraph-numbering, update-TOC compatibility concerns, and a potential argument from the opposite side, I suggest WONTFIX.
see bug 70756 which indicates some empty paragraphs accidentally get OutlineLevel set to one on them. I'd say that strengthens my WONTFIX argument.
I think the problem is indierctly covered by 149282. There was the decision NOTABUG. Sounds reasonable for me. => RESOLVED NOTABUG
Created attachment 190036 [details] Legitimate use of empty headings I disagree with the decision NOTABUG. The "compatibility feature" was probably motivated by the frequency of such empty Heading_n paragraphs in Word-originating documents. The majority of document-processing applications (Word, Writer, …) use them as basic typewriters. Word, which has poorer styling features, is more prone to produce empty heading paragraphs when users hit Enter to create vertical space. In Writer, pressing Enter after a Heading_n-styled paragraph switches to Text_Body. Therefore, empty headings are less frequent in Writer-created documents. The feature was then conceived as an automatic correction attempt for an erroneous use of the applications. Unfortunately, this approach is wrong. Empty headings can legitimately be used. I show this in LOBugEmptyHeading.odt attachment. It is a skeleton novel. Chapter numbering is used to automatically create chapter headings in the form "Chapter nn". I'd expect these headings to be collected in the TOC. They aren't because of the "feature". In addition, if one of the chapters has an explicit title, we get a serious discrepancy in the TOC where only the explicit heading is reported; all empty (implicit) headings are missing. Note also that (In reply to Justin L from comment #3) > […] Rarely are empty numberings deployed. (In > fact, pressing "Enter" after one of these REMOVES it.) is wrong. Contrary to list items, empty headings are perfectly accepted by Writer. I strongly advocate to reconsider the question. Eventually, add a compatibility check box to continue "fixing" DOC(X) documents but respect author choice of using the auto-numbering feature for their empty headings. I don't consider adding a space to make the heading as non-empty a valid workaround because AutoCorrect can delete them (and this setting may be useful elsewhere than on headings). (BTW, AutoCorrect Remove_empty_paragraphs does not seem to have any effect, even after forcing Tools>Update>Update All)
Dear Farhood, 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 https://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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug