Description: The bottom left view shows a wrong page count after inserting manual page breaks under certain conditions (see Steps to Reproduce section). This can become very annoying as soon as you e.g. want to print or export certain pages by specifying the page number in the document, as the page count that is shown in the bottom left differs from the actual number. Steps to Reproduce: How to reproduce the bug: 1. Create a new document in LibreOffice Writer 2. Press "Insert" – "More Breaks" – "Manual Break…" 3. Select "Page break" and an arbitrary style, check "Change page number" and set it to 1 4. The bottom left view will now show "Page 3 of 3 (Page 1)" although we actually have a page count of 2 (not 3) However, the bug will not occur if you: 1. Create a new document in LibreOffice Writer 2. Insert a page break (Ctrl+Return) and navigate to page 2 3. Press "Insert" – "More Breaks" – "Manual Break…" 4. Select "Page break" and an arbitrary style, check "Change page number" and set it to 1 4. The bottom left view will now show "Page 3 of 3 (Page 1)", which is correct as we now have a physical page count of 3 Actual Results: Bottom left view shows "Page 3 of 3 (Page 1)" Expected Results: Bottom left view should show "Page 2 of 2 (Page 1)" Reproducible: Always User Profile Reset: No Additional Info:
Created attachment 152640 [details] Screenshot showing the bug
I think this is the expected behaviour. Page 1 is always on the right page or on the frontpage but never on the backpage. So it can't be the second page of a document. I close this bug report as RESOLVED NOTABUG. Please feel free to change it back to UNCONFIRMD, if you don't agree.
(In reply to Dieter Praas from comment #2) > I think this is the expected behaviour. Page 1 is always on the right page > or on the frontpage but never on the backpage. So it can't be the second > page of a document. > > I close this bug report as RESOLVED NOTABUG. Please feel free to change it > back to UNCONFIRMD, if you don't agree. I don't agree. The example I provided is rather artificial and unrealistic, of course, but as it happens, I am currently writing a thesis and due to the described bug I do not get the right pages when I use "File" – "Export As → Export as PDF…" and enter some specific page numbers which I naturally take from the bottom left view (as such a document can have easily more than 100 pages and it is rather impractical to get the correct page number by counting yourself). Due to the bug, the exported pages in the PDF document are off by one or two (depending on the section of my document), which is rather annoying. So either the export/printing function or the bottom left view should be adjusted.
Regarding PDF-Export I confirm it. I remember that this issue has been discussed in the past, but I couldn't find that bug report.
(In reply to Dieter Praas from comment #2) > I think this is the expected behaviour. Page 1 is always on the right page > or on the frontpage but never on the backpage. So it can't be the second > page of a document. > > I close this bug report as RESOLVED NOTABUG. Please feel free to change it > back to UNCONFIRMD, if you don't agree. I also don't quite agree with the logic of assuming that any document that is written in LibreOffice is going to be printed double-sided. I understand where you are coming from, but oftentimes documents are printed only on one side per sheet (so that you have only front pages but no back pages) and in those situations showing "Page 3 of 3" is confusing, too. So the easy and logical fix would be to show the actual page number in the bottom left view. If I want to have e.g. the beginning of a chapter on a new piece of paper, I will have to arbitrarily add an empty page anyway.
There are many reports around the situation where people do not know about the double-sided printing feature and the related UI. IIRC there even has been some recent change around the UI for PDF export? Possibly some more improvement is possible, but not without evaluating the issues already handled.
Again, I don't agree with the evaluation that this is a pdf export issue (see comment #5). In my opinion, the logic behind the page count display view in the bottom left is faulty (if the behavior of it, that I described in the first post, is on purpose at all and no bug, anyway).
We discussed this issue in the design meeting yesterday. It's rather not a bug and intended behavior. Admittedly, when you search for page 3 but there are just 2 would be confusing but in those situations you have set up a non-standard layout, hidden pages, or you are in book layout. All those are expert features where it can be expected that users read the manual. Besides, if the number shows not the total count but the visible we likely make users unhappy who expect exactly the opposite. I'll keep the ticket open as it was reopened. But the recommendation is NAB.
(In reply to Heiko Tietze from comment #8) > We discussed this issue in the design meeting yesterday. It's rather not a > bug and intended behavior. Admittedly, when you search for page 3 but there > are just 2 would be confusing but in those situations you have set up a > non-standard layout, hidden pages, or you are in book layout. All those are > expert features where it can be expected that users read the manual. > Besides, if the number shows not the total count but the visible we likely > make users unhappy who expect exactly the opposite. > > I'll keep the ticket open as it was reopened. But the recommendation is NAB. But the number does not show the total count. Consider a common document with a one-sided page layout with a cover page followed by several text pages; the number will always show one page too much. Consider that in a pdf document there is no such thing as a "front" or "back" page. These are totally non-expert circumstances. Please take a look at the latest screenshots: How is it not confusing / not a bug that if I export page 9 (as the bottom bar says "Page 9 of 50 (Page 1)") as a PDF file, I will get the subsequent page (10), because the page with the headline "Introduction" is ACTUALLY page 8 of the document?
Created attachment 152779 [details] Another example demonstrating the bug, taken from my thesis
Created attachment 152780 [details] The resulting pdf if "Page 9" is exported from the example document
(In reply to Heiko Tietze from comment #8) > Admittedly, when you search for page 3 but there > are just 2 would be confusing but in those situations you have set up a > non-standard layout, hidden pages, or you are in book layout. All those are > expert features where it can be expected that users read the manual. Where can I find this information in a manual? Book layout shows blank page and "blank page" entry. That makes it more clear. But what is the idea of that blank page, if you are not able to take this into account during printing, neither with PDF nor with a normal printer?
(In reply to Dieter Praas from comment #12) > Where can I find this information in a manual? Forwarding to documentation. @Olivier: Do you think the current behavior can be documented straightforward or should we change the UI as requested by flx?
*** Bug 129029 has been marked as a duplicate of this bug. ***
(In reply to flx from comment #3) > due to the described bug I do not get the right pages when I use "File" – > "Export As → Export as PDF…" and enter some specific page numbers which I > naturally take from the bottom left view If this is the problem, then I believe this bug is a duplicate of bug #31606 (In reply to flx from comment #7) > Again, I don't agree with the evaluation that this is a pdf export issue > (see comment #5). In my opinion, the logic behind the page count display Two (interrelated) issues should be separated 1. automatic (default) introduction of a ‟second” page (under certain conditions) 2. how statusbar appears (as a consequence of point 1.) The main issue arising from point 1 is: (a) why is the software trying to be “helpful” by doing something that users do not expect (i.e., automatically adding a blank page when an odd page is followed by another odd page, because of page numbering restart), and (b) does not offer a way to turn “off” this automatic page insertion (bug #117231). (NB. there are plenty of use cases where one wants page renumbering in a document that is not a book or is not going to be double-sided printed) This ‟intended behavior?” is (a) almost invisible (i.e., user did not have to do anything to turn this on, no “warning” pops up), and (b) its main functional effect – inserting blank pages – can be overridden at the time of printing. Meanwhile, it inspires multiple bug reports about status bar problems (which is just a “symptom” of the automatic page insertion), a problem with on-screen editing (bug #117231), choosing pages for pdf export (e.g., bug 31606, bug 126284 ). Recently there was an attempt to improve the statusbar appearance (bug 52316 ) (which has possibly solved the PDF export page choice problem), but it does not change the ‟main issue". An obvious alternative is: (a) user has to consciously turn on the “automatic insertion” – then at least the consequences would be less surprising, and comment 8 would still apply (about reading the documentation for advanced uses).
I also have a problem sometimes with page numbers, like in PDF export. Basically, one has to choose if s/he prints empty pages. "Page 9 of 50 (Page 1)" is shown with empty pages checked. "Page 9 of 50 (Page 9 of 45 to print)" is without empty pages. But however, no point in yet another buh reports, when repororter probably didn't search for existing. Main was bug 52316 and it's closed (not sure if rightly) but we have bug 90150. In both bugs sdc.blanco@youmail.dk made comments. So this bug is redundant. *** This bug has been marked as a duplicate of bug 90150 ***
Bugs for blank pages are numerous. One type of solution would be https://bugs.documentfoundation.org/show_bug.cgi?id=52316#c18: "to not have those blanks mentioned (and accounted for, but instead, have a print option that would read something like "use double-sided printing". Not sure if it's feasible, at least it should be better explained in a separate enhancement bug, so I don't consider this bug is for that solution. Other solution is further improvement of blank pages, that was done in bug 52316. With 7-pages test ODT attachment 109735 [details] (following question from Comment 8 there): 1. You know it has 5 pages for printing, when in Status bar you see "Page 1 of 7 (Page 1 of 5 to print)" 2. In order to print "text" and "landscape" only, you need to select pages 3-4,7 with "Export automatically inserted blank pages" or easier pages 2-3,5 without that option. So, with handling of "Export automatically inserted blank pages" printing and exporting is doable. What I see a an issue - and would propose to focus this bug to - is easier way to change between (example of Text 1 page): "Page 3 of 7 (Page 3)" "Page 3 of 7 (Page 2 of 5 to print)" Currently, this is changed after print or export. Status bar section for print has only a left-click. My proposal is to add right-click to Status bar where user could change "Export automatically inserted blank pages" settings for print and export (so needed are two check boxes). Note: There's a problem with Page Count and Page Number fields, how to get for example in "text", as in footer, for pages in print of 2 and 3: Page 2 of 5, Page 3 of 5. Also not for this bug. Add Comment
Hi Laszlo. Since you already worked on this, I was free to add you to consider my proposal.
*** Bug 142449 has been marked as a duplicate of this bug. ***
*** Bug 145123 has been marked as a duplicate of this bug. ***
Dear flx, 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 https://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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug