Created attachment 91342 [details]
Example file for testing page breaks and page numbering
After a page style break it should be possible to continue the page numbering sequence by setting the option "Page number" in the Text Flow tab of the Paragraph dialog to '0' (zero).
Steps to reproduce:
1. Create a new document and add some text
2. Create a footer with Page # of N
3. Insert a page style break with Insert->Manual Break. Select Page Break and Style "Landscape". Do not check "Change page number"
4. On the new landscape page add a footer with Page # of N
5. On the new landscape page right click the first paragraph and select "Paragraph". On the Text Flow tab select "Page number" next to "With Page Style" to '1' (one)
6. Press "OK"
7. Observe that the footer shows Page 1 of 2 for the landscape page (this is correct)
8. On the new landscape page right click the first paragraph and select "Paragraph". On the Text Flow tab select "Page number" next to "With Page Style" to '0' (zero)
9. Press "OK"
10. Observe that the footer shows Page 0 of 2 for the landscape page. This is wrong, it should continue numbering and show Page 2 of 2
This is fixed already in the nightly build. If you want to verify please try a master build from: http://dev-builds.libreoffice.org/daily/master/
I am still seeing some problems in the master build.
If you use the attached test document, right click the first paragraph on the second page and set the "Page number" to 1 then "OK". You will see the the footer on the second page is now "Page 1 of 4" (even though there are only 3 pages).
Now if you edit the first paragraph on the second page again and set the page number back to 0, it will show "Page 0 of 3" in the footer. However closing the file and opening it will sort things out so the second page correctly becomes "Page 2 of 3".
Just to make sure I am testing with the correct build, this is the information from the About dialog.
Build ID: fed8a0b291eca0565071da27d6fb7c7c5f331dcd
TinderBox: Linux-rpm_deb-x86@45-TDF, Branch:master, Time: 2013-12-31_00:40:04
Interesting I get 1/3, 2/3 and 3/3 so all good on OSX.
Testing in Win8 but can't manage to open LO due to a known JRE bug infinite loop error message madness. I missed windows :)
Miker which OS are you on?
I have tested on both Windows 8 and Ubuntu 13.04.
Please make sure you set the page number to a different value before setting it back to zero.
When you create a new file from scratch it is fine in the nightly build so something has been fixed, but there are still problems when you set to a different value then back to zero.
This has never been confirmed and it's a bit unclear if it's still a problem according to the last comment. That being said, moving to UNCONFIRMED so QA gets fresh eyes on it. Thanks
can you -again- check if this still persists with the latest nightly build?
Setting to NEEDINFO.
After providing the requested info, please reset this bug to UNCONFIRMED (should it be persisting) or WORKFORME (should it be solved with a newer LO version).
I can still reproduce this bug by following the steps outlined above using version 126.96.36.199.alpha1+.
However when closing and re-opening the file the correct page numbers are shown so it is relatively minor.
Ah ok, so this basically is a one time opening problem and after saving again page numbers are correct? Interesting.
I saw this behavior when I was working on a large brief recently....that being said, I couldn't figure out how to reproduce it consistently....it was indeed a problem though because if I exported as pdf before closing it and reopening it then the pages would be wrong in the pdf.
Can not reproduce with current LO 4.3.5.
(In reply to miker169 from comment #2)
> If you use the attached test document, right click the first paragraph on
> the second page and set the "Page number" to 1 then "OK". You will see the
> the footer on the second page is now "Page 1 of 4" (even though there are
> only 3 pages).
There is Bug 52316 and probably a duplicate Bug 57710.
I can reproduce, but is this a duplicate of bug 52316 then?
Win 7 Pro 64-bit Version: 188.8.131.52.alpha0+
Build ID: b13534de022972131b46f93f5ada90af155eec9e
TinderBox: Win-x86@62-TDF, Branch:MASTER, Time: 2015-02-19_00:21:37
Created attachment 116072 [details]
table of page numbering
I am getting slightly different results.
Step 7 showed 1 of 3 for first page and 1 of 3 for landscape page.
Step 10 showed 1 of 2 for first page and 0 of 2 for landscape page.
After save and reload it was 1 of 2 and 2 of 2.
If I did not save it and instead inserted another page break of None after the landscape page then now the numbering is 1 of 3, 0 of 3, and 1 of 3. Saving it corrects it to 1 of 3, 2 of 3, and 3 of 3.
I think that when the landscape page break is changed from 1 to 0 in Text Flow it explicitly sets it to page 0 instead of the default carry on numbering. Save and reload forces it to read the value. It is not like the default style where you can have the "With page style" unchecked and with it the page numbering because you are using a different style.
The 1 of 3 showing for the two pages could be that the count is keeping the landscape page number 0 and then counting the new landscape page 1.
Windows Vista 64
Build ID: 88805f81e9fe61362df02b9941de8e38a9b5fd16
Build ID: af75d7a4c99414fabbd31b9df590266d28574fb1
TinderBox: Win-x86@39, Branch:master, Time: 2015-05-26_00:20:30
It looks like this change might have something to do with it: https://gerrit.libreoffice.org/#/c/5681/
** Please read this message in its entirety before responding **
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 on a currently supported version of LibreOffice
(5.1.5 or 5.2.1 https://www.libreoffice.org/download/
If the bug is present, please leave a comment that includes the version of LibreOffice and
your operating system, and any changes you see in the bug behavior
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave
a short comment that includes your version of LibreOffice and Operating System
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)
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: http://webchat.freenode.net/?channels=libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!