Created attachment 47026 [details] Pls. see original report With attached sample document and "LibreOffice 3.4.0RC1 – WIN7 Home Premium (64bit) German UI [OOO340m1 (Build:11)]" print results are completely unusable. I print pages 5-7 from "test101.odt" and see With HP OJ6110 (default WIN7 drivers): Table: borders missing Envelope object: crippled Radio buttons on last page under "Vertrags-Details": Printed at the end of the document and much too big Footer LibO label: missing With Okipage 14ex (default WIN7 drivers): Table: borders missing Envelope object: crippled Radio buttons on last page under "Vertrags-Details": missing Footer LibO label: missing PDF export is ok OOo3.1.1 prints the same document correctly That was ok with LibO 3.3
Created attachment 47029 [details] Print results You can see my print results in Postscript files created with "Dell open print driver" (I think it's in the WIN drivers repository ore somewhere available for free): myprint5.ps: Both envelope pictures vrom OLE object messed up (envelope too small, "@" not visible correctly) Borders in table are missing LibO symbol in footer is missing myprint6.ps: Borders in table are missing LibO symbol in footer is missing No idea what the blue bar has been in the original document myprint7.ps: Radio Buttons behind "Mehrwertsteuer" missing LibO symbol in footer is missing The results also are visible printing a PDF with FreePDF (what IMHO uses an Apple PS printer.
Created attachment 47030 [details] Repaces defective original sample document In sample document Envelope OLE DRAWing object was missing
Created attachment 47059 [details] Output on Linux with LO-3.4.0-rc1 It looks much better on Linux with LO-3.4.0-rc1. It is with our network printer. I can't see the driver name anywhere.
Table borders seem to be missing during the print-out if the document contains any graphic (like company logo). However they are fulli exported to the PDF file under LO however they dissapear again if you export the file to PDF using virtual print drive (like PDF Creator).
(In reply to comment #4) > Table borders seem to be missing during the print-out if the document contains > any graphic (like company logo). However they are fulli exported to the PDF > file under LO however they dissapear again if you export the file to PDF using > virtual print drive (like PDF Creator). Forgot to add that the bug is present in the newly released LO 3.4 (not only in the RC version)!
I think bug is confirmed by comments 4,5. May be many users like me can't use LibO for the very basic job "printing a text document with Tables and DRAW objects", so I will nominate this one for "Bug 35673 - LibreOffice 3.4 most annoying bugs" @Cédric: Please feel free to reassign if it's not your area!
.
*** Bug 37992 has been marked as a duplicate of this bug. ***
*** Bug 38041 has been marked as a duplicate of this bug. ***
*** Bug 37975 has been marked as a duplicate of this bug. ***
I have the same problem. This version of Writer is not usable for now
*** Bug 38228 has been marked as a duplicate of this bug. ***
(In reply to comment #12) > *** Bug 38228 has been marked as a duplicate of this bug. *** This is fine with me. Note however: The fact that LO 3.4.0 messes up printing and that in all former version I never got the spell checker working is a blocking issue for my multi-lingual environment.
*** Bug 38609 has been marked as a duplicate of this bug. ***
Could this issue be considered as a blocker for release 3.4.1 ? I've read about an 3.4.1rc3 for another blocker. IMHO (and also in my humble company ;) ) it's a blocker for 3.4 deployment. We have many documents with a logo and a tables with borders which will be unprintable. Thanks !
(In reply to comment #15) > IMHO (and also in my humble company ;) ) it's a blocker for 3.4 deployment. A poor workaround is to export to PDF (what works fine) and to print the PDF. I doubt that can be fixed before 3.4.2
We already have 3.4.1-rc3, so it is too late to add any other fix. The blocker was the bug #38590. It was regression against 3.4.0, caused heavy data loss and affected almost all Linux users. I am afraid that this bug can't be considered as a blocker because there is the workaround, ... Anyway, I have increased the priority. Cedric, is there any chance to fix this for 3.4.2?
So we'll wait for 3.4.2 !
*** Bug 38839 has been marked as a duplicate of this bug. ***
*** Bug 38865 has been marked as a duplicate of this bug. ***
This bug makes LibO 3.4.0/3.4.1 completely unusable.
*** Bug 38897 has been marked as a duplicate of this bug. ***
I agree with VITRIOL... printing documents is a basic feature that cannot be so messy... it's urgent to fix this in 3.4.2.... I will stick to LibO 3.3.3 till this issue hasn't been fixed... the pdf workaround is not acceptable in a productive environment
Defining the PDF workaround as a solution is a lazy programmer's answer. Printing a doc is the basic of a Word Processor. In parallel, the Foundation will work on far much more 'geeky' features. This has nothing to do with quality. Such behaviours are the root of free software's reputation vs commercial products.
@desaunay, tommy27: no doubt this one will be picked up asap. All involved people are aware this is needed for production environments.
(In reply to comment #25) > @desaunay, tommy27: no doubt this one will be picked up asap. > All involved people are aware this is needed for production environments. I hope so. But how do you explain this: "LibreOffice 3.4.1 fixes several bugs that affected the previous version, and can be safely deployed for production needs by most users." this comes from your release announcement... http://blog.documentfoundation.org/2011/07/01/libreoffice-3-4-1-provides-stable-new-features-for-every-user/ I think most users need a word processor that can print without any issue, so LibO 3.4.1 cannot be safely used by them. please, understand what is the point of my critics... I'm not ranting against you... I know that the LibO 3.4.x development is still work in progress and is still affected by many bugs... I use the 3.3.x series and I'm very happy with it, and I know that sooner or later Lib 3.4.x will be stable. the problem is about newcomers, people who download LibO for the first time... if their first experience with LibO is affected by such a serios bug like the present one, they will not probably give LibO a second chance... my suggestion is to be more prudent with your release bullettins... you cannot tell people that 3.4.1 is almost ready for production needs while it still have such important bugs...
I tried - as far as provided - all attachments from the duplicate issues. Prints on Ubuntu, does not print on Windows
@Cor It's worse: The borders (of tables and frames) appear mostly as pretty bold lines elsewhere in the printed document.
hmm, appologies. I printed 4 of the usable attachments from the issues, and none showed the strange line. But just tried the fifth, and indeed, that one (Copia de Plantilla_Defensoria-OpenOffice.ott) does have the problem. This all on WinXP, BTW So then might turn out that we have more than one issue at hand?
The strange lines appear in the attached 'Print results' (i.e.: 'myprint5.ps', 'myprint6.ps') by Rainer Bielefeld (see Comment #1), and--as far as I remember-- they appear also in all attachments of bugs, which I have marked as a duplicate of this bug 37488. I believe it's a single issue... ;)
The original report also was concerning crippled DRAWing printing in documents with table.
Tor, a windows-only bug for you
Cédric's first guess that it would be the lcl_DrawDashedRect() method in sw/source/core/layout/paintfrm.cxx that needs debugging was wrong, I didn't see that method getting called at all when printing the "Copia de Plantilla..." test document from one of the duplicate bugs. (This is apparently the simplest document we have to reproduce the problem? Can somebody come up with an even simpler sample document that exhibits the bug, please?) (Sigh, debugging this will cause paper waste;)
(In reply to comment #33) > (Sigh, debugging this will cause paper waste;) On windows, you can use a virtual pdf printer (like PDFCreator), the bug is still present with this kind of printer. I'll add a simple odt file with the bug : - print (even virtual pdf printer) : no border around the table - export to pdf : it's ok - delete the image : print or export, it's ok (Win 7 Pro 64 bits, LibO 3.4.1 french with english ui) I think if you solve the problem with this "not real life" document on virtual pdf printer ... you can successfully test with "real life" document and "paper waste" printer. ;-)
(In reply to comment #33) > Can somebody come up with an even > simpler sample document that exhibits the bug, please? - Open Writer - Insert a table - Insert a image into a cell via Insert > Image > From file... - Print That's all. > (Sigh, debugging this will cause paper waste;) You can use a PDF virtual printer for testing.
Created attachment 48801 [details] Simple odt file with the bug
Created attachment 48802 [details] Lean test document Yes, Sir! :-) My new test kit contains: newsample3.odt: test document to reproduce all (?) problems except "Table lines appear somewhere in the document newsample3.pdf: print result with FreePDF print (same results with DELL free PostScript Printer) newsample3results.odg: Print results with marked errors I saw BTW, if you find out why the little OOo logo can't be deleted: "Bug 34186 - Can not delete Picture"
Not even necessary to install a 3rd-party virtual PDF printer; the "Microsoft XPS Document Writer" can be used to demonstrate, too, it seeems. (I don't know if that is always present, or came with MS Office?) Good.
(In reply to comment #38) > (I don't know if that is always present, or came with MS Office?) I think that it comes with .NET Framework.
Simple sample with "strange line": - 'header_border_image.odt' (14 KB) - 'header_border_image.pdf' (9 KB) - 'header_border_image.eps' (7 KB) 1. Text document, Page style 'Defaut' with 'Header on', 'Bottom Border only', Width 0,50 pt, Color 'Light blue' 2. Insert > Image 'x.png' 3. Saved as 'header_border_image.odt' 4. Exported as 'header_border_image.pdf' 5. Created 'header_border_image.eps' with PDFCreator 6. Print... or 7. Open 'header_border_image.eps' with GSview...
Created attachment 48819 [details] Sample files .odt, .pdf, .eps
No need for any more reproduction instructions or sample files, thanks. Comment #35 has instructions for a minimal test case, and is enough. And printing to XPS and using the XPS viewer allows me to reproduce just fine without actually printint to paper, I won't bother with any 3rd-party print-to-pdf or print-to-postscript tools.
Created attachment 48978 [details] Minimal sample document Just an 1x1 table and an image. If the image is the last selected item, the bug shows up, if some part of the table is, it doesn't. Or something like that.
I have been debugging this for some days but not really come up with anything that would tell me what the problem actually is... I know that in the buggy case, GDIMetaFile::Play( OutputDevice* pOut, sal_uLong nPos ) in vcl/source/gdi is called with a metafile containing just 55 elements, in the non-bug case, 96 elements. But at what stage the table (and its borders, or the lines forming the borders, or whatever) get dropped, no idea.
"Minimal sample document" seems to show only the table problem, but not the (table related?!) Drawing print problem from my "Lean test document".
That is intentional. One kind of bug per bug report.
@Tor: It's your decision, I am pretty sure that both effects at least have the same root, the crippling only appears with table in document.
(In reply to comment #43) > Created an attachment (id=48978) [details] > Minimal sample document > > Just an 1x1 table and an image. If the image is the last selected item, the bug > shows up, if some part of the table is, it doesn't. Or something like that. In my test document ( comment 36 ), the problem "non printing" table border always occurs. - If you select "nothing" (cursor in first position): problem - If you select the image : problem - if the cursor is in the table with nothing selected : problem - if you select the word "first" from the first cell : problem - if you select the whole first cell : problem - if you select the whole table : problem Only case the border are printed : you select the whole table and , in the print dialog , you choose to print "Selection" (default choice) and not "All pages". Oh and perhaps a new bug ( I've still not searched bugzilla) : - Something (e.g. the table ) is selected. - You choose "Print" - In the print dialog, default choice for "Range and Copies" is printing "Selection" - You choose to print "All pages" - Then choose again to print "Selection" - Crash !
Please, for the sanity of developer(s) trying to debug this problem, let them (us) concentrate on just the simplest minimal test document from now on here in this bug report, OK? And no speculation whether some problem with a completely different outcome (a crash) is related, thanks.
FWIW, he is some debugging output showing what GDIMetafile "actions" are present in the non-buggy vs. buggy case when printing the sample document from comment #43. OK: WinSalPrinter::StartPage() GDIMetaFile::Play (2): nPos=-1 count=96 PUSH MAPMODE SetMapMode(new) returning at 826 MAPMODE SetMapMode(new) setting maMapMode=rNewMapMode at 864 origin=(-568,-568) scale=(1/1,1/1) at 889 LINECOLOR FILLCOLOR MAPMODE SetMapMode(new) returning early, identical mode PUSH LINECOLOR PUSH LINECOLOR RECT POP PUSH LINECOLOR RECT POP PUSH LINECOLOR RECT POP PUSH LINECOLOR RECT POP POP PUSH PUSH ISECTREGIONCLIPREGION POP POP PUSH CLIPREGION TEXTLANGUAGE LINECOLOR COMMENT LINECOLOR FILLCOLOR POLYLINE COMMENT TEXTLANGUAGE LINECOLOR COMMENT LINECOLOR FILLCOLOR POLYLINE COMMENT TEXTLANGUAGE LINECOLOR COMMENT LINECOLOR FILLCOLOR POLYLINE COMMENT TEXTLANGUAGE LINECOLOR COMMENT LINECOLOR FILLCOLOR POLYLINE COMMENT POP LAYOUTMODE LAYOUTMODE FONT TEXTALIGN TEXTFILLCOLOR FONT TEXTALIGN TEXTFILLCOLOR FONT TEXTALIGN TEXTFILLCOLOR PUSH PUSH ISECTREGIONCLIPREGION LAYOUTMODE TEXTLANGUAGE PUSH MAPMODE SetMapMode(new) returning early, identical mode PUSH CLIPREGION PUSH ISECTRECTCLIPREGION BMPSCALE POP SetMapMode(new) returning early, identical mode POP POP SetMapMode(new) returning early, identical mode FILLCOLOR LINECOLOR RECT POP POP PUSH ISECTREGIONCLIPREGION POP POP SetMapMode(new) setting maMapMode=rNewMapMode at 864 origin=(0,0) scale=(1/1,1/1) at 889 SetMapMode(new) returning early, identical mode WinSalPrinter::EndPage() Not OK: WinSalPrinter::StartPage() GDIMetaFile::Play (2): nPos=-1 count=55 PUSH MAPMODE SetMapMode(new) returning at 826 MAPMODE SetMapMode(new) setting maMapMode=rNewMapMode at 864 origin=(-568,-568) scale=(1/1,1/1) at 889 LINECOLOR FILLCOLOR MAPMODE SetMapMode(new) returning early, identical mode PUSH LINECOLOR PUSH LINECOLOR RECT POP PUSH LINECOLOR RECT POP PUSH LINECOLOR RECT POP PUSH LINECOLOR RECT POP POP PUSH PUSH ISECTREGIONCLIPREGION POP POP LAYOUTMODE PUSH PUSH ISECTREGIONCLIPREGION LAYOUTMODE TEXTLANGUAGE PUSH MAPMODE SetMapMode(new) returning early, identical mode PUSH CLIPREGION PUSH ISECTRECTCLIPREGION BMPSCALE POP SetMapMode(new) returning early, identical mode POP POP SetMapMode(new) returning early, identical mode FILLCOLOR LINECOLOR RECT POP POP PUSH ISECTREGIONCLIPREGION POP POP SetMapMode(new) setting maMapMode=rNewMapMode at 864 origin=(0,0) scale=(1/1,1/1) at 889 SetMapMode(new) returning early, identical mode WinSalPrinter::EndPage()
@Nicolas R: Your Crash observation seems not to be related, I filed new "Bug 39159 - PRINTING: Switching radio buttons "Selection <-> All" Crashes"
Worked with former LibO versions.
Sigh, I now realize that an unknown part of my reproduction successes has actually been bogus: If one has a part of a document "selected", and then File:Print, the idiotic default is that it prints just the selection. I had not noticed that it defaults to printing just the selection. (That is IMHO a horrible feature, but no doubt if we would "fix" it, people would scream how that is an insult to the users, makes LO totally unusable, and especially unsuitable for left-handed people working in the construction industry, or something.) At the moment I am not capable of reproducing the bug with either my own trivial test document (either the one attached, or a similar one constructed from scratch), or the "Copia de..." sample document. This is with a relatively fresh build of vclmi.dll and swmi.dll from the 3-4 branch, but otherwise stock LibreOffice 3.4.0rc2 (I think). I will now try to reproduce with the latest 3.4.2 beta or something...
OK, with the 3.4.1 final installed in a VM I can indeed reproduce now again, both with the "Copia de Plantilla"... document (sigh, why can't we have sample documents with *short* and *simple* names?) and with a minimal test case constructed on the fly out of a 1x1 table with an image. (And this time I made sure that I did *not* print just the selection.) Will now then try to replace the vclmi.dll and/or swmi.dll DLLs with the ones freshly built for debugging and see if the bug goes away...
Created attachment 48999 [details] Another minimal test case Now, with this test case, I definitely see the bug even if I make sure not to have anything selected. Both with 3.4.1 final as such, and with a freshly built vclmi.dll.
And here is the same kind of debugging output from printing that t.odt, with the table (its borders) not visible in the output: WinSalPrinter::StartPage() GDIMetaFile::Play (2): nPos=-1 count=96 PUSH MAPMODE SetMapMode(new) returning at 826 MAPMODE SetMapMode(new) setting maMapMode=rNewMapMode at 864 origin=(-3265,-568) scale=(1/1,1/1) at 889 LINECOLOR FILLCOLOR MAPMODE SetMapMode(new) returning early, identical mode PUSH LINECOLOR PUSH LINECOLOR RECT POP PUSH LINECOLOR RECT POP PUSH LINECOLOR RECT POP PUSH LINECOLOR RECT POP POP PUSH PUSH ISECTREGIONCLIPREGION POP POP PUSH CLIPREGION TEXTLANGUAGE LINECOLOR COMMENT LINECOLOR FILLCOLOR POLYLINE COMMENT TEXTLANGUAGE LINECOLOR COMMENT LINECOLOR FILLCOLOR POLYLINE COMMENT TEXTLANGUAGE LINECOLOR COMMENT LINECOLOR FILLCOLOR POLYLINE COMMENT TEXTLANGUAGE LINECOLOR COMMENT LINECOLOR FILLCOLOR POLYLINE COMMENT POP LAYOUTMODE FONT TEXTALIGN TEXTFILLCOLOR FONT TEXTALIGN TEXTFILLCOLOR FONT TEXTALIGN TEXTFILLCOLOR LAYOUTMODE PUSH PUSH ISECTREGIONCLIPREGION LAYOUTMODE TEXTLANGUAGE PUSH MAPMODE SetMapMode(new) returning early, identical mode PUSH CLIPREGION PUSH ISECTRECTCLIPREGION BMPSCALE POP SetMapMode(new) returning early, identical mode POP POP SetMapMode(new) returning early, identical mode FILLCOLOR LINECOLOR RECT POP POP PUSH ISECTREGIONCLIPREGION POP POP SetMapMode(new) setting maMapMode=rNewMapMode at 864 origin=(0,0) scale=(1/1,1/1) at 889 SetMapMode(new) returning early, identical mode WinSalPrinter::EndPage()
@Tor thanks for your efforts trying to fix this annoying bug. I keep my fingers crossed!!!
However, with a freshly built swmi.dll I don't see the bug. Whether this is because I built it with (partial) debugging, or because of some code changes in it since 3.4.1, no idea...
I guess it is possible that we are lucky, and some change in the code after 3.4.1 has (accidentally) fixed also this problem...
@Tor: What ever that might help for your investigations: I just did a test with my more complex sample documens and compared result 3.4.1 and a Daily 3.4 Branch Dated 2011-07-08. I see much progress concerning the table printing, a blue table not printed at all with 3.4.1 now is printed correctly, and also the resting table lines seem to be complete. A print with HP OJ3110 looks perfect, also the Drawing object is no longer cropped. It might be that there still some PS print problems exist. FREEPDF shows some line thickness issues (grey instead of black), and the envelope still is cropped, but in a different way I saw that before. IMHO this is a different issue that had been hidden by the terrible other cropping Result via Dell PS Printer still looks horrible on screen, some better in print, but same as from OOo 3.1.1, so that is not our problem. My summary: Table print problem fixed / worksforme (IMHO we can change status) Remaining Drawing Cropping problem IMHO different issue, If you do not object, I will file a new report for that.
@Tor & Reiner great!!! teamwork pays!!!
I can confirm Rainer's finding. Tested with LibO 3.4 Daily [libreoffice-3-4~2011-07-10_23.10.17_LibO_3.4.1rc1_Win_x86_install_en-US_de_fr.exe on WinXP]: 1. 't.odt' (Another minimal test case - Attachment 48999 [details]) Works well (with line width 0,50 pt; that's another problem) 2. 'Copia de Plantilla_Defensoria-OpenOffice.ott' (bug 38609, Attachment 48348 [details]) Works well 3. 'header_border_image.odt' (Attachment 48819 [details]) Works well 4. 'sample embedded calc wont print border cells.odt' (bug 37975, Attachment 47590 [details]) Works pretty well (only a left border is missing; probably another problem)
No objections, so due to latest results I add target and close this one for now. I will leave comments for follow ups concerning remaining problems with different reasons.
*** Bug 37867 has been marked as a duplicate of this bug. ***
great seeing this resolved! Thanks a lot all. (I missed this earlier, because I'm on vacation and missed too that my subscription to libreoffice-dev list somehowe got broken). As state/solution I would rather advice just 'fixed'. Not only because it was broken (though the reason solution are not spit out), but also beacuse it is much clearer to people looking for the coming 3.4.2 release that this is fixed. Now 37488 does not show on http://dev-builds.libreoffice.org/pre-releases/src/bugfixes-libreoffice-3-4-release-3.4.2.1.log ...
fixed ! Cheers !
@Cor Nouws: I prefer the "WORKSFORME" because we can not know how t4h problem has been repaired. For good reasons the Bugzilla Help text for FIXED is "A fix for this bug is checked into the tree and tested." These fixes are very reliable. The pseudo-fixes are much less reliable, sometimes the problem reappears. For me it eases the work if my Bugzilla search separates such "real reviewed fixes" from "problem vanished somehow, nobody knows why".
@rainer: well, OK, I can agree. I thought setting to 'Fixed' would help to get this kind of automagically resolved issues in the generated list of fixes. But since it does not (as explained to me on the list), I have no reason to stick to my proposal.
@Cor: For me information how those lists are created also was nes.
See also bug 32849.
*** Bug 37670 has been marked as a duplicate of this bug. ***
I see that this bug was moslty on Windows, but I have a problem with messed-up printing on Ubuntu 11.10 32-bit with LibreOffice 3.4.2. It is a simple text-only document, created in LibreOffice. I don't know if you need sample file for this or not, but the result is far from usable - almost one in 10 words is wrongly printed. If I export document to PDF, and print it, everything looks OK. I also tried the latest 3.4.4 from LibreOffice PPA, but that one prints the same as 3.4.2. Interestingly, if I open the same document in OpenOfice 3.3, and print from it, it looks fine. If you need sample, please tell, I'll send it here.
Hmm, I tought that I was filling the bug for "[Bug 37488] PRINTING result completely messed up" but, after sending, I see different title of the bug. If this isn't the right place, should I make a new one?
@Zarko Zivanov Summery concerning your Comment 73: this bug can be closed again?
I will file a new bug for my issue, with the same text. Sorry for the inconvinience.
@Zarko Zivanov A simple "Yes" would have been enouth ;-)