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.