This is not a dup to 86359, though the title is similar. I have 142 letters to be printed, mail merge works so far okay as far as I can make it out. It shows the 142 as output sheets, and it runs from 1 to 142 at producing those. But that single document is a mess: loading takes a few minutes. And then the first page is okay, but is shown as "1 /283" in the lower left corner status bar in PRINT PREVIEW - all further references are PRINT PREVIEW, too. 284 would be 2 times 142, so you'd expect empty pages, but there are none. The second page is really crappy and shows as "1 3/283". And so forth. Scrolling to the end ("1 141/283") is actually Nr. 72 of the letters. Those above 73 don't show up, using the scroll bar, only by clicking 'To Document End ' it works. Using my simple sample files attached to 101259, a similar crazy page numbering pops up, though there are only 3 letters to be concatenated. In PAGE PREVIEW the page numbers likewise show "1 3/5"for the second page.
Could you test, if the problem is still in the latest master: http://dev-builds.libreoffice.org/daily/master/?C=M;O=A I don't remember which OS you use, so: https://wiki.documentfoundation.org/Installing_in_parallel
Tried 5.3.0.0.alpha0+ of 16 August. It produces the 3 form letters from the extremely simple set provided with 101259, but still shows the silly page denomination at print preview, like 1 3/5.
The "crazy page numbering" is probably a little incomprehensible, but correct. "1 141/283" = virtual page 1 on physical page 141 of 283 physical pages. I'm open for and idea for a better status text, which is more "intuitive" for the user. Probably a popup with an explaination would help? There had been some discussion, when I worked in the area: https://listarchives.libreoffice.org/global/design/msg07516.html So you have a single page document, in the default double page mode. MM works by concat'ing documents and new documents in double page mode always have to start on the right page, as the left page is the back of the previous right page. Therefore MM / LO has to insert an empty page between the documents with an odd page number, From your example: 142 becomes 142 + 141 empty pages = 283 _physical_ pages. And since these are individual documents, every document starts at page one. If you had more pages in your MM you would also see multiple "page two". So numbering the pages per document is correct. Now there is the print preview, which makes it even more complicated, as it depends on the print setting. If you go to "Print..." => Tab "LibreOffice Writer" => "Pages", you'll find "print empty pages". It defaults to "off". If you set this checkbox, close the dialog and re-generate the print preview... tadaa - empty pages. I would like to have a better UI. Ideas welcome. https://listarchives.libreoffice.org/global/design/msg07516.html
The "crazy page numbering" is probably a little incomprehensible, but correct. "1 141/283" = virtual page 1 on physical page 141 of 283 physical pages. I'm open for and idea for a better status text, which is more "intuitive" for the user. Probably a popup with an explaination would help? There had been some discussion, when I worked in the area: https://listarchives.libreoffice.org/global/design/msg07516.html So you have a single page document, in the default double page mode. MM works by concat'ing documents and new documents in double page mode always have to start on the right page, as the left page is the back of the previous right page. Therefore MM / LO has to insert an empty page between the documents with an odd page number, From your example: 142 becomes 142 + 141 empty pages = 283 _physical_ pages. And since these are individual documents, every document starts at page one. If you had more pages in your MM you would also see multiple "page two". So numbering the pages per document is correct. Now there is the print preview, which makes it even more complicated, as it depends on the print setting. If you go to "Print..." => Tab "LibreOffice Writer" => "Pages", you'll find "print empty pages". It defaults to "off". If you set this checkbox, close the dialog and re-generate the print preview... tadaa - empty pages. I would like to have a better UI. Ideas welcome.
Okay, for the explanation. Totally not okay for an evangelist of FOSS. "Teaching the user" is a bad alternative to "doing things right from the start". And for mailmerge program, the user doesn't have to understand inner workings of a software. If user has a single page document and wants to merge for n recipients, the user expects n single pages, not 2n-1 pages, with n-1 virtual pages and n real pages. This, sorry, *is* crazy. And it is inconsistent. I did work with virtual pages in a publication, but then empty pages versus full pages would not show (starting a new chapter on the right side). If you always displayed virtual page numbers versus real page numbers once virtual pages exist, it would be better. Though it would still not be good for mail merge, because nobody knows why a mail-merged document should always start on the right side.
(In reply to Uwe Dippel from comment #5) > Okay, for the explanation. > Totally not okay for an evangelist of FOSS. "Teaching the user" is a bad > alternative to "doing things right from the start". I definitely don't know what "doing things right from the start" is. Granded we have a legacy codebase, but we're modernizing stuff were possible. > And for mailmerge program, the user doesn't have to understand inner > workings of a software. If user has a single page document and wants to > merge for n recipients, the user expects n single pages, not 2n-1 pages, > with n-1 virtual pages and n real pages. This, sorry, *is* crazy. This is how Writer works internally and this can't be changed. It's one of the basic principles how Writer does internal layouting. This also includes the "everything is a frame" principle. You can change your page setting to single page layout AKA no front or back page, if you really want to prevent the empty pages. But this has probably other drawbacks, you don't want. Now it's no problem to hide internals from the user. As I said, I would be happy to see suggestions for a better and more consistent UI, especially since the print preview really depends on the print settings, which is very non-obvious for the user. Feel free to post your ideas to the design mailing list, or open an enhancement bug report. I thought about moveig at least the "print empty pages" as a button to the preview, so it can be toggled. The preview pages are cached, so it should be fast. > And it is inconsistent. I did work with virtual pages in a publication, but > then empty pages versus full pages would not show (starting a new chapter on > the right side). Virtual page numbers always exist internally. Most time they don't differ from the real ones, but if you MM a document, which has page fields with page numbers, you definitely don't want to use the physical number. > If you always displayed virtual page numbers versus real > page numbers once virtual pages exist, it would be better. I don't understand your suggestion. Please provide an example. The print preview has: "1 10/20". Writer has "page 10 of 20 (page 1)" > Though it would still not be good for mail merge, because nobody knows why a > mail-merged document should always start on the right side. The page setting can be double, right only or left only. The default page setting for documents is double. MM doesn't change anything here. And it just inserts empty pages in double mode AFAIK (didn't check).
*** Bug 89777 has been marked as a duplicate of this bug. ***
If not mail merge speicific, then this looks like a duplicate of Bug 52316.
*** Bug 98307 has been marked as a duplicate of this bug. ***