Bug 89708 - MAILMERGE: Add option to prevent inserting extra blank pages
Summary: MAILMERGE: Add option to prevent inserting extra blank pages
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: Other All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard: target:5.2.0
Keywords:
Depends on:
Blocks:
 
Reported: 2015-02-27 06:42 UTC by HD
Modified: 2018-04-18 16:50 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
image of print dialog (1.07 MB, image/png)
2015-02-27 06:42 UTC, HD
Details
Stack Trace hang unotxdoc.cxx -> viewsh.cxx when activating Print dialog from print preview mode (22.88 KB, text/plain)
2016-01-29 05:27 UTC, V Stuart Foote
Details

Note You need to log in before you can comment on or make changes to this bug.
Description HD 2015-02-27 06:42:09 UTC
Created attachment 113728 [details]
image of print dialog

Mail merge inserts extra blank pages between each document, therefor
it's hard to print document by selecting pages.

Many users want to determine pages to print while watching the preview
in print dialog. 
For example, to print "record 2" and "record 4" you'll select "2,4",
but no pages are printed.

This problem does not resolve even if you turn off the option:
"Print automatically inserted blank pages".

Please add an option to avoid the behavior that blank pages are inserted
in the merge.
Comment 1 Cor Nouws 2015-02-27 08:25:48 UTC
Hi HD,

Thanks. I understand the request.
Would be quite hard, I'm afraid, since it hooks on basic page lay out behavior...
Educating the users is much easier...

But let's set to new enhancement and see how it goes.

Cheers,
Cor
Comment 2 Jan-Marek Glogowski 2016-01-04 16:02:20 UTC
There is no way to prevent the blank pages.

But we already don't display blank pages in the LO print dialog, as you can see in the image (no pages previewed AKA 0/0, because "print empty pages" is not selected).

So the print range selector needs to evaluate the range according to the "print blank pages" setting. This is doable.

Now we get the "problem", that the preview range doesn't match with the displayed page numbers in the document window - not sure which is worse.

All this can become - in any way - frustrating for the user.
Comment 3 Commit Notification 2016-01-22 14:23:43 UTC
Eilidh McAdam committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=3c1a343f6936f1dcefdf79a677f8c26ce29676e6

tdf#89708 Adjust print page range for unprinted blank pages

It will be available in 5.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 4 V Stuart Foote 2016-01-29 05:27:29 UTC
Created attachment 122266 [details]
Stack Trace hang unotxdoc.cxx -> viewsh.cxx when activating Print dialog from print preview mode

On Windows 10 Pro 64-bit en-US with
Version: 5.2.0.0.alpha0+
Build ID: d1a49df6833ff16f5cbaf98534eaae62693e520b
CPU Threads: 8; OS Version: Windows 6.19; UI Render: default; 
TinderBox: Win-x86@39, Branch:master, Time: 2016-01-29_02:02:17
Locale: en-US (en_US)

@Jan-Marek, getting a hang with the new code in print preview mode when IsPrintEmptyPages() is disabled, i.e. ignoring blank pages, and then selecting the Print button.

Can't get past this to compare behaviors with IsPrintEmptyPages() enabled, which allows the Print button and dialog.

Think the unotxdoc.cxx was touched in this area for the patch.
Comment 5 Commit Notification 2016-01-29 23:38:44 UTC
Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=1296f9dc9e502abd8422dfeee1ac7747a82aee17

tdf#89708 Fix crash on printing from print preview

It will be available in 5.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 6 Jan-Marek Glogowski 2016-01-29 23:46:08 UTC
I pushed a patch to fix the crash. I originally didn't test print preview, so thanks for the test. Took me a while, because I saw an other bug, which I thought was related to the patch.

Now finally I realized that print preview with empty pages is buggy. Originally I thought it's a problem of Eilidhs patch, but it's also broken in 5.1 and 5.0.
For my test document it shows 83 pages, but you can just scroll to page 41. Actually page-down is working, but page up brings you straight back to page 41.

If nobody beats me to it I'll open a new bug next week.

Hopefully you can test again. Sorry for the inconvenience and thanks for your time, Stuart.
Comment 7 V Stuart Foote 2016-02-02 14:00:48 UTC
On Windows 10 Pro 64-bit en-US with
Version: 5.2.0.0.alpha0+
Build ID: 91c072b473beadda01a38dbc26086207c7b4d145
CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; 
TinderBox: Win-x86@39, Branch:master, Time: 2016-02-02_06:12:40
Locale: en-US (en_US)

The preview in the print dialog, and the print preview mode, set print range when blank pages are suppressed in a reasonable fashion.

This works around the blank pages as suggested. Could probably be backported to 5.1

However, when opening the print dialog from the print preview mode (Print button or Ctrl+P) the dialog opens with preview at first page--but the "Pages" field keeps the page from the preview mode with counts including the blank pages.

Submitted that as bug 97505