Created attachment 53347 [details] Document that doesn't print well I have a problem with messed-up printing on Ubuntu 11.10 32-bit with LibreOffice 3.4.2 and 3.4.4. It is a simple text-only document, created in LibreOffice. The result of printing 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. I also took a look at content.xml onside odt file, and the text inside looks normal to me (no special symbols or anything).
Created attachment 53348 [details] Printing results Inside the archive there are 4 pictures: LO342 - printing from LibreOffice 3.4.2 LO344 - printing from LibreOffice 3.4.4 LO342-B - printing from LibreOffice 3.4.2, but after applying bitstream vera sans font to all text (very weird) OO33 - printing from OpenOffice 3.3 (the same is from PDF generated in LibreOffice 3.4)
NOT Reproducible with reporter's sample and "LibreOffice 3.4.4RC2 - WIN7 Home Premium (64bit) German UI [OOO340m1 (Build:402)]". I will concentrate my research on 2 words: Should be shown342 342B Version No 0.11 ssss ° °° ° Start first line Trac je s ras je °ra° je @Zarko Zivanov: Please contribute information concerning your Printer / Settings / Driver/ ...
Printer is Samsung ML-2850ND. Driver is default Postscript driver for this model (selected at the time I installed Ubuntu 11.04; Make and model: Samsung ML-2850D Foomatic/Postscript (recommended)). I didn't have problems with this printer in other programs, as I can remember. What other settings should I post? I didn't try LibreOffice from Windows (I have a XP installation, but I rarely use it; I'll try to print the same document from Windows and post the results, but it won't be before sunday). I did try printing from another machine, also with Ubuntu 11.10 32-bit, but the results were the same.
I have exactly the same problem, It happens with existing and new documents, with Writer and Calc creating a pdf and printing it is my work-arrond. printing the same document with MS-Word/Exel (running with Wine) works fine I'm Using: Ubuntu 11.10 (64 Bit) (Language: English) LibreOffcie 3.4.3 (English Interface, Language Dutch) Samsung CLX-3185 Printer Cups Driver: Samsung CLX-3175 Foomatic/foo2qpdl (recommended)
I am not able to reproduce it either. It seems to be somehow specific to your printer setting. A workaround exists. => it can't block the release => lovering the severity a bit. It would be great to attach the problematic ps file that is sent to the printer. Hmm, "Print To file" generates PDF. I am going to ask on the developer mailing list how to get the ps file.
OK, it seems "File/Print/Options/Print to File" works as expected. The PDF is sent to the printer on recent CUPS systems, see http://lists.freedesktop.org/archives/libreoffice/2011-November/021073.html It would be interesting to compare the PDF file generated by "File/Export as PDF" and "File/Print/Options/Print to File". Zarko, Ronald, could you please attach the two PDF files?
Created attachment 53767 [details] Export to PDF
Created attachment 53768 [details] Print to file One of the machines that had the problem with printing was reinstalled with Linux Mint Debian Edition, and printing the same document from its LibreOffice (3.3.3) produces correct results. So, I guess it has something to do with Ubuntu. What puzzles me, is that on Ubuntu, OpenOffice prints correctly. I compared all printer and font settings in OpenOffice and LibreOffice, and they are the same. Anyway, here are my two PDF files. Thanks for looking into this!
(In reply to comment #9) > Created attachment 53768 [details] > Print to file Given that the "print to file" PDF looks good, I suspect something in the CUPS/driver/printer stack. Does printing the "print to file" PDF work well? Please try to print it directly with lpr, not with a program like evince / okular / xpdf / ... Open a shell and give the command: lpr /path/to/Trac-PrintToFile.pdf
Both files are printed wrong when using lpr. It didn't cross my mind to try something like this before submitting a bug report. I'm very sorry to have wasted your time, as the problem is obviously in CUPS. Just one more question, if you maybe know: does this means that OpenOffice/Evince/etc don't use lpr, but something different for printing?
(In reply to comment #11) > Both files are printed wrong when using lpr. OK, then I'm closing this bug for now, as it seems this is not a LibreOffice bug. If further analysis by CUPS guys finds out that it is a LibreOffice bug after all, please reopen this bug and add the results of the analysis, or a pointer thereto. > Just one more question, if you maybe know: does this means that > OpenOffice/Evince/etc don't use lpr, but something different for printing? Well, they do something similar to what lpr does (meaning sending the data to print with an HTTP POST to CUPS), but they also transform the data before sending it to CUPS. This transformation may "work around" the bug in CUPS, that's why I wanted you to test with lpr. For example, for an ODT file, OpenOffice/LibreOffice knows that CUPS can't handle ODT, so it transforms the file into PostScript (older versions of OpenOffice.org) or PDF (newer versions of LibreOffice), and then sends it to CUPS. That's a transformation of data that cannot be avoided if one wants printing to work! As to evince, CUPS supports PDF so evince could theoretically send the PDF unchanged to CUPS. However, it is likely evince at least transforms the PDF a bit, for example by removing PDF features that CUPS does not support, maybe flattening the PDF, changing the resolution of embedded images to match the printer's resolution or things like that. It is also possible that evince converts the PDF to PostScript and send PostScript to CUPS, simply because it has not converted to a "PDF-based printing workflow" yet. I mean: older versions of CUPS did not support PDF, one *had* to send them PostScript (or pure text), so maybe Evince still uses that, to be compatible with these older versions of CUPS, or because they did not have a good reason to change something that works. The same holds for e.g. Okular. When I say "evince does this or that", it is most probably not evince itself, but a library it uses, such as poppler or gnome-print (for okular, kdeprint instead of gnome-print). As to xpdf, it is not CUPS-aware, so it uses lpr to print, but it converts the PDF to PostScript and sends PostScript to lpr, which forwards it to CUPS.
Many thanks for detailed explanation, I didn't know most of that stuff. As for Ubuntu, it is/was an error in its ghostscript for cups driver. There is a solution in their still not official repository (more details at http://bugs.launchpad.net/ubuntu/+source/ghostscript/+bug/891074) that solves the problem. And once more, sorry for taking your time.
OK, since we have final/definitive confirmation this is not a LibreOffice bug, I'm setting this bug to CLOSED. Precise description of the bug is at http://bugs.ghostscript.com/show_bug.cgi?id=692687#c2 for those interested.