Created attachment 94462 [details] 1-bit colormap image: looks fine but prints as "black box" LibreOffice 4.1.5.3 Ubuntu 12.04 64 bit (will attempt to test on 4.2.x shortly). Sorry I can't confirm what version the bug would have come in. See attachment, and attempt to print it! For me, the image shows fine in the document, and it shows fine in the "print preview". However, when printed to paper, it is a solid black box with distortion on the top 10% of the black box (sort of gray garbled stuff). The image itself (you can extract from the .odt) is a .png image that gives these properties doing "file filename.png" in a terminal: PNG image data, 1029 x 479, 1-bit colormap, non-interlaced If I EXPORT test-tomatoes.odt to .pdf, it will print fine. Also, the image itself will print fine from an image viewer program. It is only within LibreOffice (same image tried in LibreOffice Writer and LibreOffice Draw) that the image will print as this "black box". Somehow, I am guessing LibreOffice is not able to handle such "1-bit images" but this is a valuable format for black and white printing!
Sorry, the attachment thinks it is "plain text" but I can't attempt to specify .odt as the attachment type? Any advice welcomed. It should be a standard .odt file.
I have placed it in google drive as well so you can download it from there until I sort out how to properly have it attached here: https://drive.google.com/file/d/0B0WVXg1DL6ducEZqRGJCd2hmNHc
Thanks for the help in redefining the document type to "odt" in the attachment. I have heard from another colleage this issue does not appear for them, either with Linux or Windows LO. I will need to do further testing, but possibly it is an issue with my printer driver (again, however, the "black box" only appears if I print from LibreOffice: printing from PDF viewer or image viewer print fine). I will attempt to report back here if that is the case.
Ubuntu 14.04 x64 LibreOffice 4.2.4.2 release I am unable to reproduce this. Marking this as WFM. If you are still able to reproduce with 4.2.4.2 release please mark the bug as UNCONFIRMED once again. Just a heads up - I printed to file instead of print to printer (should be no difference).
Most definitely not resolved, I just hit this on Ubuntu 16.04.3 LTS with LibreOffice 5, 5.1.6.2 Build ID 1:5.1.6~rc2-0ubuntu1~xenial2. UI Renderer: default. A simple 1-bit PNG prints on paper as an all-black square, whether it has a color map or not. "Printing to a file" exports a valid PDF which will print OK, but printing directly to a real printer fails. (OpenGL is not in use and I can't test with it, since with OpenGL switched on LibreOffice won't start at all.)
Created attachment 139467 [details] Simple demo document from 5.1.6.2
(In reply to Janne Korkkula from comment #6) > Created attachment 139467 [details] > Simple demo document from 5.1.6.2 I reproduce. Arch Linux 64-bit Version: 6.1.0.0.alpha0+ Build ID: 40c33132cfa6582dfccf17e787f10dd4dbd0819d CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on February 24th 2018
Note for testers: feel free to resize the image to be much smaller. No need to waste toner.
Created attachment 140233 [details] QR code sample image I'm seeing this in Writer on QR codes, which is a very common image to include these days. Attaching a sample made thusly: qrencode -t png -l H 'https://bugs.documentfoundation.org/show_bug.cgi?id=75285' -m 0 -s 4 -o bug75285.png libreoffice-5.4.5.1-1.fc27.x86_64
* printing shows the bug * export to PDF, and print to file shows the bug * export to XHTML does not show the bug
(In reply to Thorsten Behrens (CIB) from comment #10) > * export to PDF, and print to file shows the bug Not for me.
Created attachment 140469 [details] 'bad' b/w PNG
I've just discovered this problem as well with b/w PNG graphics used in my Writer document (under Linux Mint 18.3, and LibreOffice v6.0.2.1. (Note: LibreOffice OpenGL is off, and 'Convert Colours to Greyscale' is unticked.) My Observations are: * Printing to laser or inkjet printers exhibits the same problem. * Out of 12 black/white PNG graphics, only 2 print OK but I can't see any difference between them and they were all edited in Gimp using the same process. * Changing mode to greyscale (but no change to content), all print OK. * Exporting the Writer page first to PDF then printing the PDF, all images print OK. * Printing the graphic directly from Gimp editor prints OK. * Printing exactly the same document from Writer on a Win7 PC prints OK. I've attached a sample 'bad' b/w PNG (indexed 1-bit palette) and a rare 'good' b/w PNG in case it helps. My workaround at the moment is to change the mode of each graphic to greyscale after graphic editing is completed. A solution would be much appreciated.
Created attachment 140470 [details] 'good' b/w PNG
Same problem here. Also I have the same problem with printing to PDF. Evince shows just a black rectangle.
Created attachment 140890 [details] This is a screenshot what a pdf with this problem looks like in evince. Enclosed is a screenshot of what a pdf looks like. I also tried xpdf as the viewer but with the same results.
It reproduced. On Version: 5.4.5.1 Build ID: 1:5.4.5-0ubuntu0.17.10.5 CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk3; Local: ja-JP (ja_JP.UTF-8); Calc: group
Any information when this bug will be dealt with? I have quite a lot of documents with 1-bit-pngs in them, and to convert them all to greyscale just for the workaround would be quite demanding.
(In reply to ge.huber from comment #18) > Any information when this bug will be dealt with? I have quite a lot of > documents with 1-bit-pngs in them, and to convert them all to greyscale just > for the workaround would be quite demanding. Please be patient. If you are not a paying customer, you just have to wait. Thorsten assigned this to Vasily so that is something.
(In reply to Buovjaga from comment #19) > > If you are not a paying customer, you just have to wait. Is there a way to pay for a speedup for a fix of this specific bug? This is a serious question of course.
(In reply to ge.huber from comment #20) > (In reply to Buovjaga from comment #19) > > > > If you are not a paying customer, you just have to wait. > > Is there a way to pay for a speedup for a fix of this specific bug? > This is a serious question of course. I will leave that to Vasily and Thorsten to answer (and maybe contact you privately).
Dear Vasily Melenchuk (CIB), This bug has been in ASSIGNED status for more than 3 months without any activity. Resetting it to NEW. Please assigned it back to yourself if you're still working on this.
Have tried to reproduce on current master and on lo52, but could not get the error. Had someone recently checked this...?
Created attachment 146670 [details] test doc with PNGs from rhynas No repro with current master - attaching test doc with last two PNGs from rhynas
(In reply to Janne Korkkula from comment #6) > Created attachment 139467 [details] > Simple demo document from 5.1.6.2 Still printing as black square. My printer: Canon LBP7018C Arch Linux 64-bit Version: 6.2.0.0.alpha1+ Build ID: 72e6269b88a32a672e00d2c25f0d0400038d1360 CPU threads: 8; OS: Linux 4.19; UI render: default; VCL: gtk3_kde5; Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US Calc: threaded Built on 14 November 2018
Issue exists as described Windows 8.1 pro x64 Libreoffice 6.3 and Libreoffice 6.1.6.3 In the older version Loffice 5.4.3 the bug does not appear. If anyone knows a version 6.xx that is ok let us know in the comments.
So after much testing (Linux & Windows), I now believe this is NOTOURBUG. While in 2018, on an opensuse Leap, I was able to repro, by now (using versions as old as 5.2.7), I don't see it anymore (neither print to PDF, nor export as PDF, nor print to CUPS-connected printer and intercepting the spool file shows the prob). Versions: * opensuse Tumbleweed - 20200108 * cups-filters-1.25.0-2.2.x86_64 * libcups2-2.3b6-1.3.x86_64 * libcupsimage2-2.3b6-1.3.x86_64 * cups-2.3b6-1.3.x86_64 This was very likely some bits in the CUPS filter chain meddling with the image - LibreOffice is passing down: 4 0 obj <</Type/XObject/Subtype/Image/Width 1230/Height 1230/BitsPerComponent 1/Length 5 0 R /Filter/CCITTFaxDecode/DecodeParms<</K -1/BlackIs1 true/Columns 1230>> /ColorSpace/DeviceGray /Mask 6 0 R Whereas earlier CUPS output then converted that into: 8 0 obj <</Subtype/Image /ColorSpace/DeviceRGB /Width 1230 /Height 1230 /BitsPerComponent 8 /Filter/DCTDecode/Length 42130>>
(In reply to Janne Korkkula from comment #6) > Created attachment 139467 [details] > Simple demo document from 5.1.6.2 Well, Thorsten, I am still able to repro with this document while printing to physical printer. Also, you talk about CUPS, but people on Windows could also repro. After printing, I opened the file /var/spool/cups/d00211-001 in Okular and it did not show a black box, but the QR code. Arch Linux cups-filters 1.27.1 libcups 2.3.1 cups 2.3.1 Version: 7.0.0.0.alpha0+ Build ID: 9b8180dfb71e139d78be487967f741e1f9f46d51 CPU threads: 8; OS: Linux 5.5; UI render: default; VCL: kf5; Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US Calc: threaded Built on 7 February 2020
(In reply to Buovjaga from comment #28) > Well, Thorsten, I am still able to repro with this document while printing > to physical printer. Also, you talk about CUPS, but people on Windows could > also repro. > Ok, fair enough - then its NEEDINFO for the Windows side, perhaps stavrosss can share some more details of his setup (printer model, does it also happen when printing to file for that printer, or perhaps using this XPS foo). > After printing, I opened the file /var/spool/cups/d00211-001 in Okular and > it did not show a black box, but the QR code. > Well the spool file then gets processed by CUPS before hitting the physical printer, so we'd need to get the final representation of that file. Could you try and extract that via this howto: https://wiki.ubuntu.com/DebuggingPrintingProblems#Getting_the_data_which_would_go_to_the_printer ? (for completeness sake - with your description, for Linux, it is still NOTOURBUG)
(In reply to Thorsten Behrens (CIB) from comment #29) > Well the spool file then gets processed by CUPS before hitting the physical > printer, so we'd need to get the final representation of that file. Could > you try and extract that via this howto: > https://wiki.ubuntu.com/ > DebuggingPrintingProblems#Getting_the_data_which_would_go_to_the_printer ? > > (for completeness sake - with your description, for Linux, it is still > NOTOURBUG) Yeah, I get it. I tried the steps, but /tmp/printout was not created. Maybe it is because the use of "FileDevice yes" was restricted in later CUPS versions. Let's wait for Windows results.
Dear Rik Shaw, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
Dear Rik Shaw, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-FollowUp
I face the same bug trying to print some QR code generated by the qrencode utility as PNG 1-bit colormap: it displays correctly on the screen and can be correctly exported as PDF, but when I print from LO writer to the printer, I get a black rectangle. My version of LibreOffice is 7.0.2.2 and I run Ubuntu 20.04.2 LTS on a 64-bits OS. I would be happy to help changing the status of this bug to unresolved.
(In reply to Pierre François from comment #33) > I face the same bug trying to print some QR code generated by the qrencode > utility as PNG 1-bit colormap: it displays correctly on the screen and can > be correctly exported as PDF, but when I print from LO writer to the > printer, I get a black rectangle. > > My version of LibreOffice is 7.0.2.2 and I run Ubuntu 20.04.2 LTS on a > 64-bits OS. > > I would be happy to help changing the status of this bug to unresolved. Please see comment 27