Issue 58919

s/Black/Blank
and
s/bank/Blank

sorry

I did a workaround in
sw/source/ui/dbui/dbmgr.cxx

in function:
sal_Int32 SwNewDBMgr::MergeDocuments( SwMailMergeConfigItem& rMMConfig, SwView&
rSourceView )

change:
USHORT nStartingPageNo = rSourceShell.GetVirtPageNum();
to:
USHORT nStartingPageNo = (rSourceShell.GetVirtPageNum() == 1) ? 0 :
rSourceShell.GetVirtPageNum();

its looks work, the blank pages not appear...

Joesny

Reassigned to HI.

HI->OS: Sounds similar to issue 56615

HI->OS: I've got a bugdoc which hopefully help you to catch the problem.
Note: Bugdoc is made by mailmerge but you can build such doc by hand, so it is
not a mailmerge issue!

- Load bugdoc and print it 
-> you should get after all recipient a blank page excepting the last recipient
Expect: 4 pages with all recipients without a blank page

- print only page 1 and 2
-> Second recipient is not printed
Expect: 2 pages with recipient 1 and 2

- print page 1 until 3
-> recipient 1 - blank page - recipient 2
Expect: 3 pages with recipients 1, 2 and 3

Created attachment 34432 [details]
load bugdoc

Changed issue type to patch, subcomponent to code.

*** Issue 61565 has been marked as a duplicate of this issue. ***

---Aditional important comment from intersol from issue 61565:

This problems had beed resolved in 2.0.2 RC3 but there is no hint for the user.
The option is inserted in the Print Options. The settings is saved per document
so  the use have to go to 
1. File -> Print -> Option -> Uncheck "Print automatically inserted blank pages"
for current document 
OR
2. Tools -> Options -> Writer -> Print -> Uncheck "Print automatically inserted
blank pages" for current document for the new created documents.

I think the solution was implemented but it will generate a LOT of support
problems because the "Mail Merge Wizard" does not include this options even if
this an specific option related to merging. 

I would keep it a an interface BUG :) and implement a shorcut to Print ->
Options and/or a explanatory text on one of the wizard page.

The explanatory text must be present on Step #6 or BEFORE.
The buton to open the Print -> Options or directly the checkbox must be present
in (Step #8 under select printer.).

The people must know about this feature before the last step because they may
forget to return to the wizard if they click edit in Step #6.

*** Issue 63388 has been marked as a duplicate of this issue. ***

I suffered from this while creating my first single document mail merge document.

I was told by the german staroffice newsgroup that OpenOffice.org thinks that
everyone uses duplex printers and adds automatically empty pages. 
Although you can supress those thru the options which were told here, this is
extremely annoying for starters and for those who print > 1000 letters having
999 useless pages in thr document, waste of space and memory.

This awkward solution should be changed to 1 page behavior default.
A check box should pop op when I want to save a single document saying:

[] I use duplex printing (or something similar)

I suppose more than 50 % of all users don'T even have a duplex enabled printer. 

I suffered from this while creating my first single document mail merge document.

I was told by the german staroffice newsgroup that OpenOffice.org thinks that
everyone uses duplex printers and adds automatically empty pages. 
Although you can supress those thru the options which were told here, this is
extremely annoying for starters and for those who print > 1000 letters having
999 useless pages in thr document, waste of space and memory.

This awkward solution should be changed to 1 page behavior default.
A check box should pop op when I want to save a single document saying:

[] I use duplex printing (or something similar)

I suppose more than 50 % of all users don'T even have a duplex enabled printer. 

I get the same problem when I mail merge with three records in a database. 
Page 1 and 3 are correct, i.e. correspond to the data in records 1 and 3. 
Record number 2 is not merged, but an empty page 2 is created.

Interesting enough the mail merge wizard recognised that three records are 
available in the database table. You can browse all three records before you 
merge (and only get two).

Target changed to 2.x

As I understand, actually the merge-program changes the first paragraph and 
activates automatically the options "insert break" and "with page style". 
 
Why not show this as options somewhere in the wizzard, so that the user 
understands what's happening and could adapt it to his wishes. 
[x] page break before every new record 
[ ] new sheet for every new record 
This options could be explained in the help-text. 
 
That would include the possibility, even not to insert a page break. And that 
would offer to use the mail-merge to create flexible listings. 

*** Issue 81271 has been marked as a duplicate of this issue. ***

This is a serious issue... and still confusing and irritating my users in
version 2.3, almost two years after "joesny" first reported it.

Under no case should blank pages be added to a merge document, unless the user
has specifically requested it... and there are no such options in any merge
dialog.  Starting a new page with each record makes perfect sense, but not
adding blank pages.

If I open a saved, merged document that was a one page form merged with three
records, I expect three pages.  Instead, I get content, blank, content, blank,
content.  That is FIVE pages.  When I click on the first page, the page
indicator says "Page 1/5" when I then click on the only other next page I can
find, it says "Page 1 3/5"!!  So something is also trying to hide the blank
pages, making them extremely difficult to remove or even see, and messing up the
page indicator too.  They are visible, however, if you do a page preview of the
document.

I don't see how this really has anything to do with duplex as has been suggested
in other comments.  In our case, no printer or printer settings are ever set to
duplex before or after merging a document.  If this problem was created with
duplex in mind, then the document should have been 6 pages in the above example,
not 5.

And, although this is probably not the appropriate location for the comment-
there should be a THIRD option in the UI for the merge dialog, "create and open
new document".  It should be unnecessary to "print" the document to a file, then
turn around and manually open the document to look at it.  Simply open up a new
window with the new, merged document in it.  And that should be set as the
default option- not printing, not saving to a single file, not saving to
multiple files.

If you check user behavior- I bet 90%+ of people will want to look at what they
merged to make sure it is correct, before printing it.  Currently, this means
always having to save it out, then having to open it back up again.  And this
blank page bug is validation as to why users want and need to look at the
document before printing.

>Under no case should blank pages be added to a merge document, unless the user
>has specifically requested it... and there are no such options in any merge
>dialog.  

The reason for blank pages is the fact that the page number corresponds to left
or right pages. As the merge doesn't check whether a page number is used or not
it assigns the starting page number of the source - usually 1 - to the first
page of each resulting merge. The Writer _always_ inserts the blank pages to
fill the gaps between left/left or right/right pages. This has nothing to do
with mail merge. If we wouldn't insert this blank page printing on duplex
printers wouldn't work. You would always get two letter on one sheet.

>If I open a saved, merged document that was a one page form merged with three
>records, I expect three pages.  Instead, I get content, blank, content, blank,
>content.  That is FIVE pages.  When I click on the first page, the page
>indicator says "Page 1/5" when I then click on the only other next page I can
>find, it says "Page 1 3/5"!!  So something is also trying to hide the blank
>pages, making them extremely difficult to remove or even see, and messing up
>the page indicator too.  

That's not messing up anything. In case of "Page 1 3/5" the page indicator shows
that you are at a page with the number 1 that is the third page out of 5.

>I don't see how this really has anything to do with duplex as has been suggested
>in other comments.  In our case, no printer or printer settings are ever set to
>duplex before or after merging a document.  If this problem was created with
>duplex in mind, then the document should have been 6 pages in the above
>example, not 5.
There' no need for a trailing empty page. The printing takes care for it at the
end of the print job.

>And, although this is probably not the appropriate location for the comment-
>there should be a THIRD option in the UI for the merge dialog, "create and open
>new document".  
Which current two options do you mean that need a third option?
>It should be unnecessary to "print" the document to a file, 
>then turn around and manually open the document to look at it.  Simply open up
>a new window with the new, merged document in it.  And that should be set as
>the default option- not printing, not saving to a single file, not saving to
>multiple files.
>If you check user behavior- I bet 90%+ of people will want to look at what they
>merged to make sure it is correct, before printing it.  Currently, this means
>always having to save it out, then having to open it back up again.  And this
<blank page bug is validation as to why users want and need to look at the
>document before printing.
On page 7 of the wizard there's a button to check the resulting document. I
don't see the need to open the resulting document by default after the merge is
done. 

The wizard also takes care for printing the pages correctly. 

Issue resolved as wontfix.

Please explain why this bug was closed as WONTFIX?
- Don't you agree that there's a problem or is it just to complicated to fix?
If I do a 7 records mail merge for a 1 page document to a new document and then
convert the document to pdf (by clicking "Export as PDF file") my pdf file will
be a 14 pages pdf file with every other page blank.

I am absolutely blown away that this is now marked as "WONTFIX"!  It is most
certainly a BROKEN behavior.  Let's analyze:

1) 90%+ of printers in use today are simplex, not duplex.  So it breaks the
behavior on 90% of the printers.  This is an exaggeration.  I would be glad to
provide a poll of my 100+ user Linux user's group, if you like.  If you really
felt it was necessary to insert blank pages for duplex printers, then check the
current printer properties to see if duplex is on by default before ruining the
document.

2) Even on duplex printers, it is not necessary to send blank pages, unless you
are actually using it in duplex mode at the time.  All duplex printers I have
ever used (and I have used many) do not enter duplex mode unless specifically
requested by the application, or if left permanently "on" in the printing
subsystem (which is also exceedingly rare).

3) People don't necessarily want to use the complicated wizzard for a merge.  In
many cases, wizards can be more complex than just doing what you want without
going through lots of additional questions.

4) Saving a merged file is not the same function as printing directly.  So even
if most printers were duplex (which they most certainly are not), saving the
file should NOT have the behavior.  

5) I can almost guarantee that the vast majority of users are going to be
confused and irritated by the current behavior of inserting unnecessary blank pages.

6) Yes the page number indicator is wrong, it should not always show you as
being on page one.  If I start a brand new document and insert several hard
pages, it works correctly- it doesn't say I am on page "1" for every page I move
to.  Of course, this could be some other type of bug and unrelated to this issue.

->hvedk: The issue is set to WONTFIX because it cannot be fixed in a sensible
way without either breaking something else (like the page number and the duplex
printing) or by implementing a different left/right page behaviour of the Writer. 
The mail merge just cannot do miracles.

->crxssi: You probably didn't understand my explanation. So here it comes in a
short form.
- Each resulting document part has to start with page number 1. Otherwise f.e.
page number fields would be wrong. 
- Each page with an odd number is a right page. In a Writer document blank pages
are inserted if and odd page follows and odd page or an even page follow an even
page. Printing of such blank pages can be suppressed using
tools/options/Writer/Print/Print automatically inserted blank pages. There's
currently no such options for PDF export.
- The page number field in the status bar shows the current page number and the
number of pages. If the page number is set manually via Insert/Break/Page break
with Style and Change page number (or the related setting in Format/Paragraph)
then it also shows the index of the page. This is not related to mail merge.
- It is not necessarily possible to detect if a printer is duplex or not. This
information is not accessible on all platforms (if on any at all) that are
supported from OOo.
- If you don't want to use a wizard then use the mail merge dialog that can be
configured under tools/customize under Documents/Mail merge. This either prints
directly or saves a single file (with the same page issue) or multiple files.

The typical use case that I know about is to mail merge a letter to a list of
persons either as printouts or as e-Mail. 

What is the use case of exporting a mail merged document to a PDF-file?

Regarding PDF- you are confusing me with "hvedk"... I never used that example,
although I agree with his logic.  I consider the extra pages as a contamination
of the resulting merged output.  It makes it difficult to print, difficult to
review, and difficult to convert to PDF.

As for the wizard- I hate it.  It is confusing, long, and doesn't do at all what
I want to do, which is to simply grab a few fields from a spreadsheet and place
them in a docuemnt I have already designed.

I do understand your explanation, I just still don't agree with it.  I think it
is more broken in its current form, for more people, than it would be if the
blank pages were not added.  If the user WANTED to print it in duplex, then
having the merge contain extra blank pages defeats that and makes them print
simplex.  If the merge had no blank pages, it will still not print in duplex
unless the user had the printer locked down to ALWAYS print EVERYTHING in
duplex.  And I have *never* seen anyone do that (in 22 years as an IT professional).

Typically, using merge, the user will want separate physical pages for each
record.  But that is not ALWAYS the case.  In WordPerfect, for example, I use
merging all the time to make fancy reports in which there are more than one
record on a printed page.  I also use merging to create multipart pages, in
which one page will be cut into separate physical parts later.  Inserting blank
pages (or even new pages in these cases) tends to make that even more difficult.

I belive I understand some of the constraints with duplex.  But at a very
minimum- there should be a choice in the merge dialog if the user wants to have
artifically added blank pages or not, with the default being "no".  I would
propose this:

Page Control:  [ ] Streaming- no pages breaks between records
               [*] Page breaks- each record on a separate page
               [ ] Page breaks plus an extra blank page

I agree, this needs to be fixed, WONTFIX is not OK.

Well, I would love to know how to make the developers take notice that it is a
pretty serious problem that should be fixed and the current behavior really is
broken.  There have been half a dozen duplicate bug reports, and many people who
are not satisfied.

I fear once it is "resolved" as "wontfix", that is the end.  Any new postings of
a similar nature will just point back to this one.

os, if you are unwilling to fix this issue, would you please reassign it and
reopen it.

I also can not agree with WONTFIX.

I looked through the Wizards, and did not see anything about mail merge. The
only place mail merging is done is from clicking Print.

This problem still exists in 2.4 rc4 (m10)

I need to print envelopes from a ods spreadsheet-database, and also have a odt
template/document formated for envelopes.
I get a blank page every other record, and this is not on a printer with duplex
capability. I have to feed it 10 envelopes at a time, and then pick out half to
re-feed the printer.

Also it does not help to export to pdf and unselect the option "Export
automatically inserted blank pages" unless I should be printing my envelopes
from a pdf file??

Would this issue get more attention if I File a new bug report or vote for this
issue?

Great rejoicing!
I found where to suppress the blank pages:

After the Print Mail merge is completed and the resulting odt file is loaded,
Click Options in the Print Dialog, Then uncheck "Print automatically inserted
blank pages"

Caution, This option does not remember your preference. Remember to uncheck it
every time.

This issue is fixed after all.

That was suggested in this thread two years ago by "intersol".  But I still
wouldn't consider it fixed, I would consider that to be a "workaround"

1) The merge shouldn't put extra pages in, unless the user chooses to do so. 
Most users will have no idea why extra pages would be a hard-coded default (me
niether)

2) Most users wouldn't know where to go to try and change the supress setting.

3) What is on the screen is confusing, regardless, with the strange left/right
page numbering.

4) I think supressing the extra pages in the print dialog will not help with
"save as", when you create a report or something and want to export it as an
ASCII text file for futher editing.

*** Issue 89504 has been marked as a duplicate of this issue. ***

This "feature", which is really a serious bug, also prevents any so-called
"catalog" merge from having proper page numbers. Page number fields cannot be
added to any merges because of these "auto inserted pages". It is a serious bug
that should be fixed.

*** Issue 92761 has been marked as a duplicate of this issue. ***

I really don't mean to "beat a dead horse", but...

The reason there are so many duplicates for this issue is because it is NOT
RESOLVED.  "WONTFIX" is not suitable.

Reopened in cause of several inputs for this and many user interests.

*** Issue 102147 has been marked as a duplicate of this issue. ***

What is the default setting for Tools|Options|OOo Writer|Print > "Print
automatically inserted blank pages" ?

I still have this issue in Linux version 3.1.1. I have tried all the settings
recommended here without success. When mailmerging to print envelopes I get a
"hidden" blank page after each envelope. Opening the merged document and doing a
print preview shows each blank page. I have tried to delete then with a search
and replace with no success. Printing to a PDF created the same problem, blank
pages in what looked like portrait format. All the records are printed. After 2
days of experimenting to fix the problem I have to print only right pages to get
only valid envelopes.

I agree with the comment from "crxssi Tue Nov 13 23:05:56 +0000 2007". My
sentiments exactly. What he stated is what I was looking for when printing
envelopes.

This is a problem (bug). In looking at other issues referenced from here, this
seems to be the closest to my problem.

@ oobaum123
   >  "I have tried all the settings recommended here without success."

Except possibly the one just above yours, #desc36 ?

It has been two years since my last comment on this issue, reported 5 years
ago...  Yes, it is still a big problem for my users.  It is a frequent drain of
support time in my department trying to explain to users and help work-around
the broken behavior of OO adding blank pages in merges.

If the developers are unwilling to change the UI, can't we at least have a
system-level flag/setting somewhere to turn off the blank pages generation?

In reference to:  cornouws Fri Sep 24 20:57:02 +0000 2010 
Yes, I did turn off that option on all printers including the CUPS printer and
it did not work. I decided to try it again and this time it did work correctly
(at least for the CUPS printer), but that is because it only works after you
select print (in preparation to print the document) then turn it off. Thanks for
mentioning it again. Mine now works (or at least worked once).

There was a no fix argument posed in this thread and I have to weigh in with another common use case for mail merge: postcards, which is no different conceptually to the issues users are having trying to print envelopes, or one page documents on the typical simplex printer. The addition of blank pages makes no sense in this context. This makes these runs very cumbersome, even if the suppress printing blank pages option is used.

Note also the doubling of the page numbers makes re-starting after a print jam unnecessarily difficult. In the print dialog which has a great thumbnail viewer, this is how one would normally find their way back to a midpoint in the run, scrolling to the last printed document, noting the page number, then setting the page print range to that + 1 through the last page number, ie: resume printing where you left off. However, the page numbers in the preview don't match those in the specify print rage: in the former, the page number without the suppressed blanks is displayed and makes intuitive sense, but the "specify print range" works only with the doubled page numbers. In effect, you have two tools side by side in the same dialog box that are using different page numbering rules(!)

So, if you have 550 actual pages (or cards, or envelopes) and need to restart the printing at page 500 through 550, you can locate card #500 in the preview, verify visually it's the one you want to restart with. Butif you plug that value into the print page range you end up with not 50 but 25 printed cards (because of the suppressed page number gaps) and the pages printed will be from around the actual page 250, pages you've already printed. Ouch! Anyone doing serious mail merge work knows you need a reliable restart function as printers will always have jams, glitches, timeouts in the middle of a longer run.

Again, the "suppress printing blanks" was a decent band-aid to keep from spitting out a blank after every printed page, but failed to address the fundamental issue with page numbering in what appears to be the most common use case, where the page number should reflect the actual position of the page in the document, for various (and obvious) reasons. 

A previous poster had a good suggestion: give us an options flag for Writer that allows the suppression of the actual addition of the blank pages, and all this other difficulty and mess can be avoided. It doesn't even need to be the default, but the option to invoke it is critical to the value of Writer as a good general purpose mail merge tool. 

I also think it's time to reconsider making no blank insertions to be the default mail merge behavior.

Thanks,
Mark

*** Issue 118254 has been marked as a duplicate of this issue. ***

*** Issue 120318 has been marked as a duplicate of this issue. ***

Regina: Can you pls comment on my comment #40, made 9 months ago. Do you understand/agree that using the suppress blank pages option still leaves the user with incorrect and mismatched page numbers in preview vs print page range? Due to this, the bug cannot be listed as nofix, the current workaround introduces an egregious page numbering bug and needs to be revisited as recommended. Again, we would recommend mail merge should (actually) work for simplex printing, by default, and duplex printers should be asked to select an option to support the duplex mode. Or at least allow a working option for one page simplex mailmerge printing with accurate page numbering, which OO does not have today. Thanks, it's a big deal to many as the thread clearly shows.

I agree 100% with "Mark OB." It is hard to believe it has been almost 7 years of waiting now...

Users simply do not understand the crazy page numbering and there is never any reason that merged labels, envelopes, cards, etc should be pseudo (or real) double-sided.  If the user wants double sided, they can choose that option in the print dialog. The current method is very confusing and makes printing selected pages extremely difficult.

I have to agree that there needs to be a solution to this 'feature'.  It is ridiculous that it has gone on this long.  There should be an option to select duplex printing instead of assuming it by default when performing the merge so that an unsuspecting user doesn't end up printing 100 blank pages by accident and then has to go through and sort out the blank pages from the printed pages.  What a pain in the a$$ that was.

OK, here we go again with Laufzettel_Maske_A5.odt which is a serial document of mine with "Print automatically inserted blank pages" = OFF
The next attachment 1704 [details]A5M.odt a resulting document after merging the former into a single file (and with confidential data removed). It has "Print automatically inserted blank pages" = ON 

Observation #1: The serial print does not inherit this setting from its source document.

"Print automatically inserted blank pages" seems to be a document specific option. However, I uncheck this option for the merged document the document's modified status does not change. Step by step:
File>PrinterSettings... [Options] "Print automatically inserted blank pages" = OFF
The document remains unmodified.
File>SaveAs... <other name>
File>Close
File>Open... <other name>
The option remains unchecked in this new copy.

Observation #2: The modified document setting does not change the modified status.

Alternative method:
File>Print... [Ctrl+P], second tab, uncheck "Print automatically inserted blank pages"
Cancel the dialog
File>SaveAs... <other name>
File>Close
File>Open... <other name>
The option remains unchecked in this new copy.

Observation #3: OpenOffice applies a setting from a canceled dialog.

Created attachment 83288 [details]
Mail merge document with "Print automatically inserted blank pages" = OFF

Created attachment 83289 [details]
Merged output with "Print automatically inserted blank pages" = ON

Oh, and I forgot to stress the ovious matter of fact that there is no way to get the pages right when you print to a printer directly.

> Oh, and I forgot to stress the ovious matter of fact that there is no way to get the pages right when you print to a printer directly.

Sorry, this was a false statement. After the temporary document has been created, the final print dialog allows you to turn off the magic option.

The behaviour is controlled by registrymodifications.xcu:
<item oor:path="/org.openoffice.Office.Writer/Print"><prop oor:name="EmptyPages" oor:op="fuse"><value>false</value></prop></item>
This global setting is accessible via Tools>Options:"Print automatically inserted blank pages"

In a Writer document's settings.xcu the setting is stored as
<config:config-item config:name="PrintEmptyPages" config:type="boolean">false</config:config-item>
This document specific setting is accessible via File>PrinterSettings>[Options...]
and on the second tab of the print dialog. The document setting does not change the modified status which may be worth another bug report.

Any mail merge output inherits the setting from the global configuration. However, it should be inherited from the source document. Or may be not?

Even with the help of wikipedia I do not understand what "Duplex" means and why it requires blank sheets of paper, but I think this shouldn't be a document specific setting nor should it be stored globally. I think it is printer specific, isn't it? Dialog File>PrinterSettings... indicates configuration settings for each printer that has been selected from the list box. However, the sub-dialog [Options] writes only one item for all printers into registrymodifications.xcu

(In reply to Andreas Säger from comment #51)

> Even with the help of wikipedia I do not understand what "Duplex" means and
> why it requires blank sheets of paper

"Duplex" just means "printing on both sides of the paper".  Automatic duplexing is something a printer can do, optionally, if it has the ability to turn the paper over and print on the other side.  It can be done manually too, although this is quite a challenge for multi-page documents.

It requires blank pages if the program assumes the printer WILL be printing duplex, and yet you are actually printing something like labels, envelopes, or forms, which are NOT duplex and must not be printed duplex.  The root problem is that it should never assume a printer will default to printing duplex... that just makes no sense in any environment I have ever seen.

>, but I think this shouldn't be a
> document specific setting nor should it be stored globally. I think it is
> printer specific, isn't it?

Whether a printer can (is able to) print duplex or not is a printer setting (or a CUPS setting).  Whether you WANT it to print duplex is another, totally different setting.  I can't imagine that anyone would really want duplex printing "on" by default.

Yes, but why does printing on both sides require entirely blank sheets of paper inserted between the first printed ones? In most cases this is just a major annoyance. Anyhow, it is off topic and difficult to explain. I should set up a printer to work this way and watch it in real life.

Although you can set it up in the template of your serial letter, the output does not follow this setup. Instead it reads this property from a global setting which may be unknown and which is ON by default. If the setting is not in the registrymodifications.xcu then it defaults to ON.
I was so focussed on the document specific setting in the two print dialogs that I forgot about the third setting in Tools>Options.

Reset the assignee to the default "issues@openoffice.apache.org".