Bug 138957 - Mail merge to mailing labels creates an extra blank sheet between each printed sheet
Summary: Mail merge to mailing labels creates an extra blank sheet between each printe...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium normal
Assignee: Not Assigned
URL: https://wiki.documentfoundation.org/F...
Whiteboard:
Keywords:
: 42099 48951 134723 (view as bug list)
Depends on:
Blocks: Writer-Styles-Page Print
  Show dependency treegraph
 
Reported: 2020-12-15 20:47 UTC by Bill Sparrow
Modified: 2025-09-04 19:50 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Bill Sparrow 2020-12-15 20:47:33 UTC
Description:
When I run a mail merge to mailing labels it creates an extra blank page between each page. I have found from the forum that I can prevent these blank pages from printing by going to Tools / Options / LibreOffice Writer / Print / Print automatically inserted blank pages and remove the tick, but why is it creating them in the first place?

(Besides, turning off that option would mess things up if I was, for example, printing a book that needed to have all chapters starting on a right hand page.)

Having the pages of labels identified on screen as 1, 3, 5 as I scroll through the document is really confusing! If I want to print a single page of labels, I have to bear in mind that to print the page that is identified on screen as page 5, I need to select page 3 in the print dialog.

Steps to Reproduce:
1. Create a spreadsheet of mailing addresses
2. Create a Writer document of mailing labels using this as a source database
3. Run the mailmerge and print the resulting document

Actual Results:
An extra blank page is inserted into the merged document between each actual page of labels. The blank pages are not displayed on screen in the merged document, however the pages that are shown are numbered 1, 3, 5...

Expected Results:
The merged document should consist of a continuous series of labels


Reproducible: Always


User Profile Reset: Yes



Additional Info:
Version: 7.0.1.2 (x64)
Build ID: 7cbcfc562f6eb6708b5ff7d7397325de9e764452
CPU threads: 16; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win
Locale: en-GB (en_GB); UI: en-GB
Calc: CL
Comment 1 Timur 2021-04-09 16:38:00 UTC
This is a duplicate of Bug 48951 and NotABug. 
But let me convert it to enhancement request to have Options / LibreOffice Writer / Print / Print automatically inserted blank pages turned off by default.
Comment 2 Bill Sparrow 2021-04-12 13:39:56 UTC
Hi Timur. 

Sorry, I have just realised that you have highlighted there are actually three related reports... "bug 48951", "bug 134723", and "bug 138957". I have just mistakenly added a comment to 134723 thinking that it was my report!

I will avoid repeating my comment here, but in summary I don't think that your enhancement request is appropriate. See this comment for my reasoning...

https://bugs.documentfoundation.org/show_bug.cgi?id=134723#c3
Comment 3 Tom Walker 2021-06-07 12:00:49 UTC
(In reply to Timur from comment #1)
> This is a duplicate of Bug 48951 and NotABug. 
> But let me convert it to enhancement request to have Options / LibreOffice
> Writer / Print / Print automatically inserted blank pages turned off by
> default.

I created an account to file this as a bug as I've now been running into it repeatedly for several months, but found it already open here so I'll comment here: 

In the case of labels at least, "print automatically inserted blank pages" is not a behaviour anyone would ever want. It's nothing but a sharp edge for users who have to go and find a setting - worse, you have to turn it off *every time* you print a new document of labels.

I can see the argument that turning the setting off affects other use cases outside labels, but for labels it should always be turned off. I can see a few ways of doing it:

1. Detect/declare whether a document consists of labels, turn the setting off by default in that case.
2. Fix the problem earlier in the chain by modifying the label-producing code to alternate left and right pages (I understand this is the root cause of the issue).

I don't really see how this is 'not a bug' - it may be an intended part of the overall design, but if you look at it only from the point of view of producing labels, inserting always-unwanted blank pages that need to be turned off looks like a bug to me.
Comment 4 Timur 2021-06-07 12:58:51 UTC
User can change setting/turn it off, so that's not a bug. 
But many are not aware and it's annoying, so this enhancement.
No matter how we call it, it needs a dev to do it - even if seems like easy hack.
Comment 5 Justin L 2025-09-01 14:47:28 UTC
*** Bug 134723 has been marked as a duplicate of this bug. ***
Comment 6 Justin L 2025-09-01 14:48:16 UTC
*** Bug 48951 has been marked as a duplicate of this bug. ***
Comment 7 Justin L 2025-09-01 15:55:11 UTC
*** Bug 42099 has been marked as a duplicate of this bug. ***
Comment 8 Justin L 2025-09-01 18:02:35 UTC
-1: By default, blank pages should be printed as per comment 2 which is the normal, designed case for this "feature".

It seems that changing the default was tried in LO 4.0 (bug 42099), but reverted in 6.4 (bug 103703).

Special use cases should not (re)define default values.

Mail merges are a special use case. "48951 70+.odt" (attachment 159050 [details]) was helpfully provided in bug 48951 comment 18. There is a blank page because each page-to-print is reset to be page 1.

I have not seen any Label sample provided.
Comment 9 Justin L 2025-09-01 18:09:36 UTC
(In reply to Bill Sparrow from comment #0)
> I have found from the forum that I can prevent these
> blank pages from printing by going to Tools / Options / LibreOffice Writer /
> Print / Print automatically inserted blank pages and remove the tick

Or more easily, in the "Print" dialog there is a "LibreOffice Writer" tab that lets you turn off "Print automatically inserted blank pages".

Also available under File -> Printer Settings -> Options.
Comment 10 Bill Sparrow 2025-09-04 19:50:41 UTC
I notice that Justin L has been doing some tidying up on this group of bug reports, which reminded me of the issues, here is my input.

Summary

The bug that causes a blank sheet of labels to be fed through the printer after every printed sheet of labels still exists.

I can provide sample files if requested.


Detailed analysis

I am aware of three activities that can produce an automatic blank page.

1. When double-sided printing multiple copies of a document that has an odd number of pages. For example, with a 5 page document, after printing page 5 on the front of the third sheet, you do not want to print page 1 of the second copy on the back of page 5 of the first copy. The default behaviour of allowing the system to create an automatic blank page avoids this.

2. When double-sided printing a book in which you want all chapters to start on a right hand page, i.e. an odd numbered page (a commonly used book layout). To achieve this you can use the page styles called Left Page and Right Page, and edit the page break above the start of each new chapter to include “With page style: Right Page”. This causes the creation of an automatic blank page if the previous chapter ends on a right page.

3. When running a merge from a database. If the merge is to produce personalised letters, then the program unhelpfully feeds a blank page through the printer after every letter. It has been reported that this can be avoided by ensuring that the print on the last line of the letter does not get too close to the bottom margin of the page. If the merge is to produce self-adhesive labels, then the program feeds a blank sheet of labels through the printer in-between each printed sheet of labels. Avoiding getting too close to the bottom margin of the page does not appear be an option in this case.

The first two above are useful features that are intentionally designed into the program.
The third is unwanted behaviour pure and simple. There are no conditions in which anyone would want the program to behave in this manner. Certainly, users have discovered that unticking the option "Print automatically inserted blank pages", either in Tools / Options / LibreOffice Writer / Print, or in File -> Printer Settings -> Options, (or on the LibreOffice Writer tab of the Print dialog) will act as a workaround for this unwanted behaviour, but that is not the solution as it stops the wanted behaviour in case 1 and 2 above. Changing the default condition of this setting was tried in a release of the program, but that change was soon reverted when the negative consequences were discovered.

As an aside, I notice also that the first of the three settings above is read and cached within a document instance, and changing that setting has no effect until the document is closed and opened again.

SUGGESTION OF WHERE TO LOOK FOR THE BUG

The mail merge appears to be behaving as if the page style of the document to be created has been set to Right Page although checking it shows it is Default Page Style.

Or maybe it has something to do with the fact that the page breaks that mail merge inserts into the merged document tell it to reset the page number to 1. 
Setting the page number to 1 makes sense in a mail-merged letter, because a multi-page letter which has page numbering displayed needs each letter to start with page 1.

There is a bug report (103703) that refers to the opposite effect when printing multiple copies of a double-sided document containing an odd number of pages. Could it be that the resetting of the page number to 1 triggers the printing of a blank page, which is the desired result in that case, but if that trigger occurs in this case it is undesired behaviour.

The fact that there exists a messy workaround does not detract from labelling this unwanted behaviour as a bug.

I have found this issue to exist in an old version of LibreOffice and in Version: 25.2.5.2

Version: 7.0.4.2 (x64)
Build ID: dcf040e67528d9187c66b2379df5ea4407429775
CPU threads: 16; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: en-GB (en_GB); UI: en-GB
Calc: CL

Version: 25.2.5.2 (X86_64) / LibreOffice Community
Build ID: 03d19516eb2e1dd5d4ccd751a0d6f35f35e08022
CPU threads: 16; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win
Locale: en-GB (en_GB); UI: en-GB
Calc: CL threaded