Apache OpenOffice (AOO) Bugzilla – Issue 120382
MAILMERGE: Messed up elements (footers, tables, graphics) on mail merge prints, okay up to OO V3.2. Example attached.
Last modified: 2017-05-20 11:53:12 UTC
Created attachment 78743 [details] Example producing messed up mail merge outputs (on current LO/OOs only) I hope somebody will read this long post. But obviously something mysterious happend to OO after v3.2. I am preparing a rather complex mail letter with switching page forms (first page to standard) and backgrounds (vector drawings from Impress, linked via header), cr code and photo graphics, tables, one rotated text box and of course database fields, conditional output and so forth. I'm familiar with these things and their problems, being an early DOS-Starwriter user (yes, even with paid licenses back in the days). Surprisingly all of these features worked when I started a first run with a filled database, but the output was a complete mess though: On some (not all) pages of the generated mail letters (4 pages each) footers were dropped (including page numbers), on the first letter (or data set) some (not all) graphics were gone, on the next letter they reappeared. From some page on tables were shrunk: their text contents -no variables- were gone. Boxes moved to the wrong page. Nearly everything was affected. First I thought this had to do with the pdf export, but paper prints were messed up as well. Then I removed "suspicious" features one by one, but that also didn't help. The remaining elements were still corrupted, there was no "critical" element to be isolated. That led me to the idea that something more general could be buggy and I started to test other/former versions and this approach was successful: Apache OpenOffice Portable 3.4: buggy output LibreOffice Portable 3.5.5: buggy output OpenOffice Portable 3.0: EVERYTHING PERFECT (okay, some impress issues, because of the newer graphic source, but nothing lost during the merge process) OpenOffice Portable 3.2: EVERYTHING PERFECT (...) All are portable versions (Apache is from winpenpack, the rest from portableapps) I could find, but from the results it's obvious that the problems don't have to do with portable or not. The fact is that somewhere later than OO 3.2 the code (maybe of the mail merge component) must have been changed (in both forks) and seems to be pretty capricious now. Attached there's an example file, which is stripped to the basics and linked to the default "biblio" database, but it may be linked to any database. If you print this as mail merge you will see all of the effects I mentioned above. Remember - all these strange things won't happen in versions up to 3.2! In my original file single prints are flawless. Interestingly (only) this example file will also show another strange effect in ALL versions: Sometimes, if you run single prints the last pages will be ROTATED (not shown in the preview). This effect is not reliable, but it happens from time to time, but in all tested versions. Maybe this is a key (or predecessor) to the whole problem, so I leave it as it is.
I have tried this file and did the mail merge in my local build, seems every thing working fine...Every printed pages just looked like what presented in the document, I will attach some pic for the print results for you verifying.
Created attachment 80693 [details] Attached zip file contain the scanned pages that printed from my local build
First of all, thank you very much for your effort in this matter. Yes, your test print seems alright. Which version is your local build? This bug is confirmed for LibreOffice (and still there in the latest build) and I tracked it back to Apache 3.4 (or earlier - I believe it is somehow related to the new print preview feature). I have posted some new thoughts and observations at Libreoffice/FreedesktopOrg: https://bugs.freedesktop.org/show_bug.cgi?id=52523 Unfortunately nobody there seems to be able to fix the bug...
My local env: win xp. 32bits AOO400m1(Build:9700) - Rev. 1467923 Which is dev snapshot build I made by myself.
Print preview? So maybe it is platform related issue? As far as I know, the print preview is platform depend feature.
(In reply to comment #5) > Print preview? > > So maybe it is platform related issue? As far as I know, the print preview > is platform depend feature. Maybe, yes. As far as platforms are concerned I think there should be major difference between Linux and Windows. But I'm running it on Windows as well. The redesigned Print Preview was a new feature in Apache OO, not in LibreOffice. That's why I don't think, they will be able to fix it at LibreOffice. Nothing new there since last summer. They're more into adding new features...
(In reply to comment #0) > Attached there's an example file, which is stripped to the basics and linked > to the default "biblio" database, but it may be linked to any database. > > If you print this as mail merge you will see all of the effects I mentioned > above. I tried this on 3.4.1, with "File" - "Print..." Answer "Yes" to "Do you want to print a form letter?" Select: - Output: File - Save merged document: Save as individual documents - generate file name from Database - Field: Itendtifier - Path: some path - File format ODF It generates 59 files, and everything looks OK (no missing images or the like).
Hello Ariel, thanks for joining in... Unfortunately this workaround is no solution, because for huge mailings, hundreds or thousands of single ODFs or PDFs that still have to printed cannot be handled. I posted this workaround to the LibreOffice bugreport: (https://bugs.freedesktop.org/show_bug.cgi?id=52523) ... I have a new interesting observation (LO 3.5.5.3): During mailmerge I chose to print single PDF files (for each data set) - and all of them were okay! Mailmerging to one big PDF file produced the same mess as printing to a PDF driver or to a real printer. Again, this points to the direction of an error during some preprocessing which sometimes isn't necessary (e.g. there is no preview in this file print mode)... ... As I mentioned there, there is no preview in this mode, while if there is a preview, it already shows/predicts the bugs. This makes me believe that the error occurs, when there is a preprocessing before the preview. Even the predicted number of pages if false. There are other known issues related to that, like superfluous blank pages (there is even a checkbox somewhere to suppress them - but why do they occur anyway?) So I believe there is strong evidence that this bug (and maybe others) is related to the new print preview mode...
(In reply to comment #8) > Mailmerging to one big PDF file produced the same mess as printing to a PDF > driver or to a real printer. Let's change the test case to print to single file: - Open the attached test document - Select "File" - "Print..." - Answer "Yes" to "Do you want to print a form letter?" - On the "Mail Merge" dialog, select: - Output: File - Save merged document: Save as single document - Press "OK" With the default Bibliographic database, I get a file with 236 pages. On page 4 I can see the first mistake: the drawing on the footer with "Some box" on light blue is missing on the first merge at least (didn't check the other).
Created attachment 80698 [details] Result of printing to a single document
@zhengfan: can you reproduce with the steps on comment 9 ?
@Ariel: Yes, as I followed your description in comment 9, the "Some box" and "01 23-12 34 56 78" inside are missed. And also, such missing also happened in the print preview widget inside the print dialog, as Zack described. But seems there are no further printing error occurs, the rest part of the document seems correct. I am just wandering that whether it is a mail merge issue, or a common print issue.
some pages are messing up especially in footers