Bug 116537 - Incorrect output of mail merge print with specified record ranges
Summary: Incorrect output of mail merge print with specified record ranges
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.2.0.4 release
Hardware: All All
: medium normal
Assignee: Mike Kaganski
URL:
Whiteboard: target:6.2.0 target:6.1.0.1
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Mail-Merge
  Show dependency treegraph
 
Reported: 2018-03-21 11:40 UTC by muesliflyer
Modified: 2018-07-03 17:00 UTC (History)
5 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 muesliflyer 2018-03-21 11:40:42 UTC
Description:
When I print only a specified range of records from the data source, I get strange page ranges to be printed. I have a single page Writer document and a Calc table with three records as the data source. Here is what I get for different record ranges:

From To Result
1    1  Prints the document filled with data from first record. Fine.
2    2  Prints document with data from *third* record!
3    3  Error message: No pages to be printed available (I am translating from German
1    3  Prints all three pages. Fine.
2    3  Prints document with data from *third* record only!

I looked into mmresultdialogs.cxx but could not find anything wrong that would be obvious to me. Maybe someone can help.

Comment: I get the impression that Writer first generates an output document with all pages from all data source records and then prints a page range from this output document. Shouldn't it be better to generate an output document only for the selected data source record range and then print all of that document?

Steps to Reproduce:
1. Open attached Writer document and connect to attached Calc data source
2. Push "Serienbrief drucken" (print merged document??) button
3. Select a record range as described above

Actual Results:  
Incorrect ranges of the data source are output or an error is flagged as described above

Expected Results:
The Writer document should be printed for the specified range of data source records.


Reproducible: Always


User Profile Reset: Yes


OpenGL enabled: Yes

Additional Info:
For the attachment, please get it from here: https://bugs.documentfoundation.org/show_bug.cgi?id=116527


User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0
Comment 1 Telesto 2018-03-21 16:27:43 UTC
No repro with
Version: 5.4.0.0.alpha1+
Build ID: 9feb7f7039a3b59974cbf266922177e961a52dd1
CPU threads: 4; OS: Windows 6.29; UI render: default; 
Locale: nl-NL (nl_NL); Calc: CL
Comment 2 muesliflyer 2018-03-22 08:27:45 UTC
I installed LO 6.0.2.1 and reproduced the bug there.

Version: 6.0.2.1 (x64)
Build ID: f7f06a8f319e4b62f9bc5095aa112a65d2f3ac89
CPU threads: 2; OS: Windows 10.0; UI render: default; 
Locale: de-DE (de_DE); Calc: group
Comment 3 Buovjaga 2018-03-27 14:25:30 UTC Comment hidden (obsolete)
Comment 4 muesliflyer 2018-03-27 15:15:42 UTC
(In reply to Buovjaga from comment #3)
> Does this also happen with "Save merged document"?

No. Works fine for me (LO 6.0.2.1). When you save e.g. from 0 to 0, it doesn't save anything. And LO doesn't complain about the illegal record numbers. 

There is only a small nit I would pick with the naming of the generated files: The appended sequence numbers should be 1-based as in the GUI and not 0-based.
Comment 5 Buovjaga 2018-03-29 14:24:02 UTC
Ok, I repro with MS print to PDF.

In mail merge wizard, select address list - add - Test.ods to make the initial test case.

I used "2 to 2" range.

I bisected this to (I tried searching Bugzilla, no other bisection for this):
https://cgit.freedesktop.org/libreoffice/core/commit/?id=3c1a343f6936f1dcefdf79a677f8c26ce29676e6

commit	3c1a343f6936f1dcefdf79a677f8c26ce29676e6 (patch)
tree	1e8a21c764ec489381d6d9c63dacba12e029cbe9
parent	dfbc2f37207f11a3bafb2c5ce0dea4fcc137e527 (diff)
tdf#89708 Adjust print page range for unprinted blank pages
Depending on whether automatically inserted blank pages are to be
printed or not, the range of pages to print is expressed differently
to the pages displayed in the preview in the Print dialog - i.e. the
page range includes blank pages, whereas the preview doesn't (if
blank pages are not to be printed).

This patch adapts the range so that if blank pages are ignored upon
printing, the range can be expressed across printable pages only,
same as the Print dialog preview.

An example is a merged document of several records into a single
page letter or document - blanks are automatically put in between
documents but usually aren't displayed/printed. Previously,
printing page 2 would print the blank page between the 1st and 2nd
merged document. After this change, printing page 2 will print the
2nd merged document instead.

The "Pages" (print range) text box in the Print dialog defaults to
the current page - this patch adjusts this when blanks are not to
be printed so that it is expressed as the current page minus any
blanks since the start of the document.

Change-Id: Ic1d4d374a82c6f921bb41a97130838757c6b74b1
Reviewed-on: https://gerrit.libreoffice.org/18420

Adding jmux to CC as Eilidh is not contributing anymore.
Comment 6 muesliflyer 2018-03-29 17:34:13 UTC
Looks like you are on the right track. When I turn on "Print automatically inserted blank pages", it works as expected. All ranges of source records can be printed - of course with blank pages in between. The problem described above occurs for me only when the blank page option is not checked.
Comment 7 Buovjaga 2018-03-29 17:42:28 UTC
(In reply to muesliflyer from comment #6)
> Looks like you are on the right track. When I turn on "Print automatically
> inserted blank pages", it works as expected. All ranges of source records
> can be printed - of course with blank pages in between. The problem
> described above occurs for me only when the blank page option is not checked.

Hmm, that was not me, but just quoting straight from the commit message.

Maybe it is not a bug. Jmux can reveal the truth.
Comment 8 Timur 2018-04-18 16:50:27 UTC
I don't repro. I tried with Output: Printer. 

(In reply to muesliflyer from comment #4)
> There is only a small nit I would pick with the naming of the generated
> files: The appended sequence numbers should be 1-based as in the GUI and not
> 0-based.
One issue per bug. And that's Bug 109120.
Comment 9 Mike Kaganski 2018-06-13 14:02:48 UTC
https://gerrit.libreoffice.org/55756
Comment 10 Commit Notification 2018-06-13 16:30:24 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":

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

tdf#116537: use page #s excluding empty pages when they are ignored

It will be available in 6.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 11 Commit Notification 2018-07-03 17:00:47 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "libreoffice-6-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=240cd3e2de7446fb009f7e372da28698aeb2682d&h=libreoffice-6-1

tdf#116537: use page #s excluding empty pages when they are ignored

It will be available in 6.1.0.1.

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.