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
Confirmed:4.2.0.1:OSX NoRepro:4.3.0.0a0+:OSX 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. Version: 4.3.0.0.alpha0+ 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
Miker169, can you -again- check if this still persists with the latest nightly build? http://dev-builds.libreoffice.org/daily/master/ 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 4.4.0.0.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: 4.5.0.0.alpha0+ Build ID: b13534de022972131b46f93f5ada90af155eec9e TinderBox: Win-x86@62-TDF, Branch:MASTER, Time: 2015-02-19_00:21:37 Locale: fi_FI
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 Version: 4.4.3.2 Build ID: 88805f81e9fe61362df02b9941de8e38a9b5fd16 Version: 5.1.0.0.alpha1+ 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) http://downloadarchive.documentfoundation.org/libreoffice/old/ 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! Warm Regards, QA Team MassPing-UntouchedBug-20160920
Dear miker169, 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 with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. 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) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 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: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
I somewhat repro per steps (and not for attachment). In 7.1: > 7. Observe that the footer shows Page 1 of 2 for the landscape page (this is correct) the footer shows Page 1 of 3 for the landscape page (because 2 is page break) > 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 yes, still "Page 0 of 2 for the landscape page" but not clear why this would be wrong when we just told it to start from 0? I change to NeedInfo for an explanation what's the bug here. Note that weird counting of page break is another issue .
Dear miker169, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
Dear miker169, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-FollowUp