Bug 126284 - PDF Export: PDF shows only two pages of a document with three pages (one page is hidden in the odf document) (see comment 3)
Summary: PDF Export: PDF shows only two pages of a document with three pages (one page...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 129029 (view as bug list)
Depends on:
Blocks: Statusbar PDF-Export
  Show dependency treegraph
 
Reported: 2019-07-08 10:51 UTC by flx
Modified: 2020-02-07 21:49 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot showing the bug (33.18 KB, image/png)
2019-07-08 10:57 UTC, flx
Details
Another example demonstrating the bug, taken from my thesis (136.21 KB, image/png)
2019-07-15 10:58 UTC, flx
Details
The resulting pdf if "Page 9" is exported from the example document (54.41 KB, image/png)
2019-07-15 11:00 UTC, flx
Details

Note You need to log in before you can comment on or make changes to this bug.
Description flx 2019-07-08 10:51:52 UTC
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:
Comment 1 flx 2019-07-08 10:57:19 UTC
Created attachment 152640 [details]
Screenshot showing the bug
Comment 2 Dieter 2019-07-08 15:35:19 UTC
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.
Comment 3 flx 2019-07-08 15:55:18 UTC
(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.
Comment 4 Dieter 2019-07-08 16:16:35 UTC
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.
Comment 5 flx 2019-07-08 18:19:08 UTC
(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.
Comment 6 Cor Nouws 2019-07-11 06:53:36 UTC
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.
Comment 7 flx 2019-07-11 08:32:16 UTC
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).
Comment 8 Heiko Tietze 2019-07-11 18:50:30 UTC
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.
Comment 9 flx 2019-07-15 10:57:43 UTC
(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?
Comment 10 flx 2019-07-15 10:58:56 UTC
Created attachment 152779 [details]
Another example demonstrating the bug, taken from my thesis
Comment 11 flx 2019-07-15 11:00:01 UTC
Created attachment 152780 [details]
The resulting pdf if "Page 9" is exported from the example document
Comment 12 Dieter 2019-07-15 12:06:57 UTC
(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?
Comment 13 Heiko Tietze 2019-07-22 09:06:20 UTC
(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?
Comment 14 Heiko Tietze 2019-12-04 07:23:12 UTC
*** Bug 129029 has been marked as a duplicate of this bug. ***
Comment 15 sdc.blanco 2020-02-07 21:47:59 UTC
(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).