Page numbers change when exporting as PDF

English
,
#1

My problem can be reproduced as follows:
Load this document: http://www.astro-electronic.de/THAT_Analog_Computer_Book.odt
At the beginning is a table of contents. Right-click → Update Index.
The last index entry is on page 289. Scroll down and you see that this is correct, it’s indeed on page 289.
Use File → Export as → Export directly as PDF
Now the problem is that the page numbers have changed. What previously was on page 289 is now on page 285, and in the PDF most page numbers in the index are wrong.

P.S. Libre Office 7.6.5.2 (x86_64), Windows 11

#2

Do you consider that behavior correct in some sense?

#3

Well, I’m expecting that the page numbers don’t change in the PDF.
If the page number change, then how can I get the correct numbers in the index?

#4

I guess, that was “no”. Then that is a bug, do you agree? And this site in not a place for bug reports :wink:

#5

I’m not sure if it’s a bug, or if I’m doing something wrong.

#6

There may not be any reason for a program to behave like that. I.e., there may not be a legal reason for a program to behave like that, even if you do something “wrong”.

#7

I would consider looking for a bug only after the document is thoroughly checked for consistent and reliable formatting, which is not the case.

If you tick Export automatically inserted blank pages, page numbering is now the same in PDF and ODT.

The high ratio of direct formatting has surely a part of responsibility in the behaviour. Most of the page breaks are manually inserted (this is direct formatting). You also space vertically with empty paragraphs. The slightest change in metrics for the fonts used (or similarly, the slightest rounding in page dimensions) can affect the location where “natural” page breaks occur and create breaks where you don’t expect them.

#8

I did tick Export automatically inserted blank pages, but it didn’t solve the problem.

#9

I see that there is an idea that some non-optimal file formatting may justify such a behavior - likely to teach people by tormenting them for their sins. This could lead to confusion, and in this situation, it’s likely that the bug will not be created. So I filed tdf#161821.

2 Likes
#10

In both the .odt and my exported pdf, the title “14 Chinese Electronic Modules” occurs on page 285 and the total number of pages is 314 for both. Therefore, there is not a problem with pagination on export.


The Table of Contents is not showing the correct page numbers in the odt and, consequentially, not in the exported pdf. The Table of Contents has been damaged somehow.
If I delete the Table of Contents in the odt and insert it a new one then the page numbers match those of the actual pages in the .odt, also in the newly exported pdf

1 Like
#11

“In both the .odt and my exported pdf, the title “14 Chinese Electronic Modules” occurs on page 285”

I can’t reproduce what you wrote. After “Update Index” it’s on page 289, and after “Export Directly to PDF” it’s on page 285.

Also deleting the table of contents and inserting a new one did not fix the problem.

#13

I tested on 7.6.4.1 & 24.24.2 and the page number in the odt shows 285.
I have just tested on 7.3.1.3 and the odt showed 289. I clicked Tools > Update > Update all twice and it now also shows page 285 in index and page number

#14

I’m using version 7.6.5.2.
After using Tools → Update → Update all the page number changes from 289 to 285.
Then after using “Update Index” it changes back to 289.

#15

Note that I tested (and prepared the sample for the bug) using

Version: 24.2.4.2 (X86_64) / LibreOffice Community
Build ID: 51a6219feb6075d9a4c46691dcfe0cd9c4fff3c2
CPU threads: 24; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win
Locale: ru-RU (ru_RU); UI: en-US
Calc: CL threaded

Some details (such as fonts present on system) may indeed affect the results.

#16

This is what I’m using:
Version: 7.6.5.2 (X86_64) / LibreOffice Community
Build ID: 38d5f62f85355c192ef5f1dd47c5c0c0c6d6598b
CPU threads: 8; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: en-US
Calc: CL threaded

#17

In 7.3.1.3, I notice now that that every time I press Update All, the pagination and TOC changes.

  • On the next page after heading 7.2 Gravity on other planets (page number 196), the table (Tabelle50) has split immediately after the header row so the rest of the page is blank and Rule 1 has moved to the next page
  • I press Update All all again and Rule 1 is back on the same page as the header row and the page number is 2 pages fewer at 194

It seems there is just enough room on a page for Rule 1 and Rule 2, but only if the header row is not on the same page. Maybe some consistency could be gained by repeating the header row of the table on every page

#18

I just noticed something very odd. Load the file and update the table of contents. Scroll down to the last page. That should be page 318. Now scroll up and down with the scroll bar. Check the number of the last page again. Suddenly it’s 317. Do some more scrolling and it becomes 316. Without doing any edits.

#19

Scrolling down causes a reflow to display the destination location “accurately”. If this destination changes continuously, you definitely have something “broken” or ill-used somewhere causing ambiguity or hesitation on Writer part.

This reminds me of an undecidable dilemma with cross-references. Suppose you forward reference a location with “see page xxx”. On first pass, xxx is unknown and the reference is “placeholded” as "see page " (void a void page number). When the reference is reached, the page number is captured and backpatched. But his may cause a page flush, changing the reference. If you have several such “unstable” nested cross-references, you could enter an infinite loop where there is no stable solution. I don’t know how Writer reacts in such a circumstance.

I don’t say you have cross-references but your tables may cause the same behaviour. In particular, the white page after Tabelle 48 could participate in the phenomenon.

I notice you have “jailed” your code snippets in 1-column×1-row tables. You could have done much better with a dedicated paragraph style (for background colour and merged borders) without putting stress on Writer.

There may be a bug in the PDF exporter, but your document deserves serious polishing to eliminate any cause resulting from non-optimal structuring.

#20

Something around page 157 (between 150 and 157) produce 1 page difference, after update, pages are fine, but after export they are modified again.

#21

In the meantime I’ve modified my document and now the page numbers in the PDF are correct. Mainly I did make some images smaller. Images inside table cells also seem to be problematic. It was not necessary to split large tables into smaller ones, or to repeat the header row of the table on each page.
Nevertheless there clearly is a problem in LO. It can’t be right that after having updated the table of contents, the page numbers change by themself when you scroll through the document, without making any edits.

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.