Created attachment 195024 [details] A long document with unstable table of content Open the attached document (a modified document from https://ask.libreoffice.org/t/page-numbers-change-when-exporting-as-pdf/107328). Update the table of content. Ctrl+Click on the last element of the table of content (#14), and check that the page shown in the table is the same as the number of the page itself (shown in the footer). Export to PDF using File->Export As->Export Directly as PDF. Open the PDF, and check that the table of content shows the same page number for the last element, but navigating there, the actual page number is different.
Have tested this. Opened the document. Updated TOC. Page 300 will be the last entry. Clicked in TOC. Page 300 is last entry. Exported to PDF. Moved to TOC. Clicked on last entry. Page 300 could be seen there. So I don't find a buggy behavior with OpenSUSE 15.6 64bit rpm Linux and LO 24.2.4.2
1. Open the attachment 195024 [details] 2. Right Click the ToC -> Update Index 3. Press CTRL+LEFT click on Chapter 14 in the TOC: Notice a table with red square below Chapter 14 on page 299 (ToC says 299 too) 4. Hit Export PDF in the toolbar 5. Notice the layout in viewport changing while exporting. Chapter 14 is now on page 297. This equals the PDF export result. This happens with SINGLE page view as multipage view Another set of steps which again results in a different layout (actual steps are steps 7-10. 1-6 are more an introduction) 1. Open the attachment 195024 [details] 2. Wait until the CPU usage drops to 0% percent [motivation: CTRL+Click TOC becomes erratic if I CTRL+Click Chapter 14 while document is still loading. Depending on timing etc. Chapter 14 might be on page 294. If don't click instantly on the link, but on the other hand click before lay outing finishes; but well that's with a old machine.. you likely need a CPU profile + debug build to generate enough overhead] 3. Press CTRL+LEFT click on Chapter 14 in the TOC; Notice a table with red square below Heading 14 on page 295 (ToC says 299) 4. Go back to the table of contents 5. Right Click the ToC -> Update Index 6. Press CTRL+LEFT click on Chapter 14 in the TOC: Notice a table with red square below Chapter 14 on page 299 (ToC says 299 too) 7. Zoom out in multipage view (2 pages side-by-side) 8. Go back to the table of contents 9. Right Click the ToC -> Update Index 10. Press CTRL+LEFT click on Chapter 14 in the TOC; Notice a table with red square being moved to page 300. Page 299 only being Chapter 14 Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: c39e4f6b8a942680bc7250177c34fd034a0605e0 CPU threads: 4; OS: Windows 8.1 X86_64 (6.3 build 9600); UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL threaded
With Version: 7.0.7.0.0+ (x64) Build ID: 626ea4e62a3e5005fe9825923a1c0c5bdb61cc08 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL 1. Open attachment 195024 [details] 2. Right click ToC -> Update Index -> Chapter 14 on page 295 3. CTRL+CLICK chapter 14 4. Click Export PDF in toolbar and save it. Table with red square is temporary invisible in viewport, but re-appears when export finishes. PDF is also fine. Chapter 14 on page 295 Page layout is also NOT dependent on multipage view zoom factor (2 pages side-by-side) Appears to be regression, IMHO
1. Open attachment 195024 [details] 2. Update the table of content 3. Scroll down to the end of the document and check the page number (325) 4. Scroll up and down with the scroll bar for a few seconds 5. Check the last page number again, it has changed to 324 6. Do some more vertical scrolling 7. Check the last page number again. Now it's 323 It can't be right that after having updated the table of contents, the number of pages changes by itself without making any edits. The issue seems to be related to the size of some images. I did make some images smaller and now the page numbers in the PDF are correct.
Another way for reproducing: 1. Open attachment 195024 [details] 2. Update the table of content 3. Scroll down to the end of the document and check the page number (326) 4. Use Tools -> Update-> Update all 5. Now the number of pages is 321 6. Jump to step 2
(In reply to Telesto from comment #2) > Another set of steps which again results in a different layout (actual steps > are steps 7-10. 1-6 are more an introduction) > 1. Open the attachment 195024 [details] > 2. Wait until the CPU usage drops to 0% percent [motivation: CTRL+Click TOC > becomes erratic if I CTRL+Click Chapter 14 while document is still loading. > Depending on timing etc. Chapter 14 might be on page 294. If don't click > instantly on the link, but on the other hand click before lay outing > finishes; but well that's with a old machine.. you likely need a CPU profile > + debug build to generate enough overhead] > 3. Press CTRL+LEFT click on Chapter 14 in the TOC; Notice a table with red > square below Heading 14 on page 295 (ToC says 299) > 4. Go back to the table of contents > 5. Right Click the ToC -> Update Index > 6. Press CTRL+LEFT click on Chapter 14 in the TOC: Notice a table with red > square below Chapter 14 on page 299 (ToC says 299 too) > 7. Zoom out in multipage view (2 pages side-by-side) > 8. Go back to the table of contents > 9. Right Click the ToC -> Update Index > 10. Press CTRL+LEFT click on Chapter 14 in the TOC; Notice a table with red > square being moved to page 300. Page 299 only being Chapter 14 Somehow these seemed to be the most reliable steps. On Linux the exact page numbers are different because the document uses Arial, but that is irrelevant for the steps. Can be shortened to just 1. Open the attachment 195024 [details] 2. Update ToC 3. Zoom out so two pages are visible in multi-page view 4. Update ToC again 5. Ctrl-click chapter 14 and observe the table with the red square has moved to the next page Bibisected with linux-64-7.6 to 325fe7ab507fd8f2ca17a3db32181edf30169525 tdf#155324 sw: layout: try not to MoveFwd onto a page created by page break Let's ask Michael what he thinks.
Chapter 14 content is moving on the next page also in Version: 25.8.0.4 (X86_64) Build ID: 48f00303701489684e67c38c28aff00cd5929e67 CPU threads: 16; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded
Created attachment 205334 [details] Information on LibreOffice version
Created attachment 205335 [details] Document which has the problem
Created attachment 205336 [details] pdf created from document The problem occurs after page 140. Sometimes, already page 140 is bad. Page 142 always is bad.
I have the same problem. Updating TOC adds page breaks. The same is true with exporting to pdf. I added three attachments: 205334 Information on LibreOffice version 205335 Document which has the problem 205336 pdf created from document System information: Linux tuxedo-os 6.14.0-123037-tuxedo #37~24.04.1tux2 SMP PREEMPT_DYNAMIC Fri Jan 23 22:31:21 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux The problem occurs with the pictures on pages 140 and 142. Changing the space added to the top and bottom of the picture on page 140 finally made this picture stable, but I did not succeed with the picture on page 142. Anyhow, it is very time consuming to get pictures stable by trial and error.
Reverting unclear addition of bibisectRequest when I already bibisected in comment 6. But good to add other keywords.
It is not only a problem of pagination. With the document of attachment 205335 [details] also part of the text is missing in the pdf. In the pdf (attachment 205336 [details]), page 138 ends with "However," followed by white space until the end of the page. Page 139 continues as it should. Another strange behavior is with the Web browser preview. Figure 4.1-1 or Figure 5.1-7 (sometimes it is 4.1-1, sometimes it is 5.1-7) are displayed before the TOC and not where they should be.
(In reply to johannes.wandinger from comment #13) > It is not only a problem of pagination. With the document of attachment > 205335 [details] ... If your attachment, that you added in comment 9, has some *additional* problem, then it's *not* about the specific problem considered here. So yes, this *is* only a problem of pagination (until a developer decides otherwise), and anything else must have own reports.