Created attachment 119801 [details] issue.ods Hi, please... - Open the attached spreadsheet issue.ods - Open the page preview Note: On thew bottom left there is "Seite 0 von 1" (English translation: Page 0 of 1) I don't know why the page number starts with 0. It should be 1. It looks like a bug. This only happens for the second sheet "Oktober 2015".
Bug 77111 describes a similar issue in Writer.
Hi @OfficeUser, thanks for reporting. In your file is disable the first page number in the Format/Page/Sheet.
Hi m.a.riosv, thanks for your comments. But in fact we have a bug here. 1. The documentation says: "Select this option if you want the first page to start with a number other than 1." https://help.libreoffice.org/Calc/Sheet_1 2. For the first sheet of my attached ods-file, the page number starts correctly with 1. 3. Starting the second sheet with 0 and the first one with 1 by default would not make sense. ==> Re-opened.
Then we need to know now, where the bug is, in the program or in the help, because it's not possible set up '0' as first page. In fact creating a new spreadsheet, has the option enable and with 1 as first page, for all LibreOffice versions beginning with 3.3.4.
You cannot set your own bugs as NEW, only Unconfirmed. I confirm the problem, but before confirming the bug, we need to know how your document was created. If we create a new document with some recent version - page numbers are correct. Current behavior started from LO 3.3. OO also showed 0 but with some text it would show 3, so no regression here.
@ Timur: Thanks for your comments. The document is based on a .xlsx input. I summarize the situation... 1) Imported .xlsx or .xls files have "First page number" UNCHECKED 2) New Calc documents have "First page number" CHECKED by default 3) If "First page number" is UNCHECKED, we have the bug that the second (and maybe also a third, fourth, ...) sheet starts with page number 0 (initial bug description) Fact is that behavior 3) does not make sense, is against the documentation and is not what a user expects. For me the situation looks like... 1) Is correct behavior. 2) Could be a work around that has been introduced in build 3.3.4 to avoid 3). So a proper solution for my understanding is to... 1) Keep as it is 2) UNCHECK "First page number" by default for new spreadsheets 3) Writing a patch that if "First page number" is UNCHECKED, all sheets start with page number 1 as described in the documentation and as expected by the user.
I have reset Importance to "normal" since files imported from Excel are always affected by this bug.
Correction: "The document is based on a .xlsx input." should be "The document is based on a .xlsx import."
According to the description, I change the title to: "Fileopen: Page number is 0 instead of 1 in XLSX on all sheets, except the 1st". I'm not aware of a workaround. But, for the future, I repeat, you cannot set your own bugs as New, only Unconfirmed.
Created attachment 119966 [details] XLSX with page numbers in header shown OK only for the 1st sheet
** 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.6 or 5.2.3 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-20161108
I can still reproduce this bug with LibreOffice 5.2.3.2.
Hello good people, it would be nice if some1 tried with a daily build (as of today or tomorrow 4th March) and tested if this issue persists. And if it doesn't, mark it as duplicate of bug#95612 Thankyouverymuch :)
Tested with Version: 5.3.2.0.0+ Build ID: acd58ceaa1d792d0a16c270c56ff727321fb2aac CPU Threads: 4; OS Version: Windows 6.2; UI Render: GL; Layout Engine: new; TinderBox: Win-x86@62-merge-TDF, Branch:libreoffice-5-3, Time: 2017-03-10_19:46:34 Locale: es-ES (es_ES); Calc: group Looks fine for me. *** This bug has been marked as a duplicate of bug 95612 ***