Bug 126284 - Improve handling of blank pages in PDF export and print (see comment 17)
Summary: Improve handling of blank pages in PDF export and print (see comment 17)
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 142449 145123 (view as bug list)
Depends on:
Blocks: Statusbar PDF-Export
  Show dependency treegraph
 
Reported: 2019-07-08 10:51 UTC by flx
Modified: 2023-10-16 03:15 UTC (History)
10 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 Comment hidden (obsolete)
Comment 2 Dieter 2019-07-08 15:35:19 UTC Comment hidden (obsolete)
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 Comment hidden (obsolete)
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).
Comment 16 Timur 2021-03-23 17:36:45 UTC Comment hidden (obsolete)
Comment 17 Timur 2021-03-25 10:13:31 UTC
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
Comment 18 Timur 2021-03-26 11:27:56 UTC Comment hidden (obsolete)
Comment 19 Timur 2021-05-24 08:17:05 UTC
*** Bug 142449 has been marked as a duplicate of this bug. ***
Comment 20 Timur 2021-10-15 08:53:27 UTC
*** Bug 145123 has been marked as a duplicate of this bug. ***
Comment 21 QA Administrators 2023-10-16 03:15:05 UTC
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