Description: With a fairly long, 341 page document, TOC page numbers do not match the actual printed page numbers, which are correct. Various changes to the document, such as deleting the last half then updating the TOC work once. After that the bug reappears. The same was experienced by checking/unchecking options in Create From such as Index Marks. In other words, changes to things may work once or twice, then fail once the index (TOC) is updated or edited. A workaround was suggested to this author by a workaround for another bug in a forum (URL lost). See below steps to reproduce. Steps to Reproduce: 1. Use a big document with a very detailed outline. 2. Insert a TOC near the top, such as after title and copyright pages. 3. Use ctl-Enter to go to the next page. 4. Update the TOC if needed. Actual Results: Page numbers in the TOC are wrong, typically by a constant offset Expected Results: TOC page numbers would match page footer page numbers (which are correct). Reproducible: Sometimes User Profile Reset: No Additional Info: Workaround: 1. Delete all lines and text between TOC and text of next page. 2. Put in 2 or 3 blank lines (not sure this is needed, but is useful to be sure what one is doing. 3. Go to menu/More Breaks/Manual Break ... 4. For page style, select Default Page Style 5. check Change page number and put the correct page number for the next page in the below box. 6. Click OK (weird, huh?) (Note: I fear to reset my profile. I also do not think this worthwhile since the bug also appears in a new install of 7.6) I hope to attach 2 files: TreatiseSin.odt containing above workaround and TreatiseSinBAD.odt which exhibits the bug. These uploads are necessary as small test documents do not reliably exhibit the bug if at all.
Created attachment 192899 [details] File that exhibits the bug.
Created attachment 192900 [details] File that exhibits the workaround
Hello, thank you for reporting the bug. I can confirm that the attached file's Table of Contents do not match the actual document. I also confirmed the workaround steps you provided fixes the issue. However, I tested it in my own large document, and follow the steps to reproduce but I cannot seem to reproduce the Table of Contents being incorrect. Tested with: Version: 24.2.1.2 (X86_64) / LibreOffice Community Build ID: db4def46b0453cc22e2d0305797cf981b68ef5ac CPU threads: 16; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 6a064b1967e06e40be40817deff99d00c1a8554f CPU threads: 16; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win Locale: ko-KR (en_US); UI: en-US Calc: CL threaded
Hello Tom Sullivan, On MacOS Sonoma 14.1.2, the file you provided does show up with incorrect indices in your Table of Contents. I implemented the workaround steps you provided and they worked. I also deleted the "Table of Contents" and inserted a new one, which also worked. I used a much larger file (1804 pages) and followed the steps you provided, yet I was unable to reproduce the bug. I just used the default settings for TOC insertion and it worked as expected. These are the following two builds I used: Stable Build Version: 24.2.1.2 (AARCH64) / LibreOffice Community Build ID: db4def46b0453cc22e2d0305797cf981b68ef5ac CPU threads: 10; OS: macOS 14.1.2; UI render: Skia/Metal; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Master/Daily Build Version: 24.8.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: c4023d3ec604abfff38be2053e2989c7ec2ba8c1 CPU threads: 10; OS: macOS 14.1.2; UI render: Skia/Metal; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
I am the original reporter of this bug. Note below: Reproducible: Sometimes I believe this bug should be fixed, even if the debugging must be done on the attached "bad" file. This will enhance the reliability of the software. The "bad" file provides a rare opportunity to capture a data-dependent bug, a type of bug that is notoriously difficult to find, and of a type that can lead to security issues. "Specially crafted" appears in many CVEs. I do not intend to nag; this is my last comment of this nature. Thanks for all your hard work.