Description: I had created an A4 sheet with 2 columns and 5 rows of book labels with Calc 25.2 in PCLinuxOS. Later I went to take a print out of this with my LibreOffice Calc 25.8 RC2 installation in the same machine but Windows 10 operating system. While I could take a proper printout with 25.2 version of Calc, I only got a faint single pixel outline with 25.8. NOTE: The print preview shows the full page as expected but the actual printout is lacking. Printer used is Epson L385 in network print mode. Somewhat similar results are output if printed to PDF too inside Windows using Microsoft PDF printer. Steps to Reproduce: 1. Create the specified document with 25.2 Calc 2. Open it in 25.8 Calc 3. Print the document Actual Results: Instead of the full page only a single pixel outline of the print area is printed out. Expected Results: The printout should have been as it is shown in preview. Reproducible: Always User Profile Reset: No Additional Info: Created using Version: 25.2.5.2 (X86_64) / LibreOffice Community Build ID: 03d19516eb2e1dd5d4ccd751a0d6f35f35e08022 CPU threads: 16; OS: Linux 6.12; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Created attachment 202218 [details] Faulty printout with thin line outline only Added attachment showing faulty printout. Ignore the central text which is artifact from my experiments to debug this issues and reuse of same paper for trial printouts.
I am hesitant to upload the offending .ods file in public as it may contain images downloaded randomly from the internet.
Without a sample file, it seems difficult to reproduce the issue.
Created attachment 202232 [details] Offending document This is the offending ODS file.
Reproducible with Version: 25.8.1.0.0+ (X86_64) / LibreOffice Community Build ID: 79c9e89970bc3ff3db4125bcfe0f9de81caea069 CPU threads: 16; OS: Windows 11 X86_64 (build 26100); UI render: default; VCL: win Locale: es-ES (es_ES); UI: es-ES Calc: threaded Even in Safe Mode. When the pdf is opened with Acrobar, shows the images for a moment, and then they disappear. But it is fine with Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 7f4868348c14b305fcd75744e1e3544d0d3a5d61 CPU threads: 16; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded
A binary from the PDF obtained by printing with 'Microsoft Print to PDF'. Is it white or can you see the image? bibisected with win64-26.2 commit 850a98962c0bbf6e11eb1a571a6160d896127167 author Noel Grandin <noel.grandin@collabora.co.uk> Mon Jun 30 12:00:15 2025 +0200 tdf#166842 do not use FillColor==COL_TRANSPARENT... backportRequest 25.8
Created attachment 202275 [details] Result of printing using Microsoft print to PDF
I'm not too keen on backporting that commit in case it causes other problems. I would rather know which commit caused this regression.
(In reply to Noel Grandin from comment #8) > I would rather know which commit caused this regression. Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: e0d4d178caff1414a9a21fa57f06bc8d4d2c389a commit e0d4d178caff1414a9a21fa57f06bc8d4d2c389a author Noel Grandin <noel.grandin@collabora.co.uk> Mon Jan 13 15:03:05 2025 +0200 Change alpha behavour of OutputDevice::SetFillColor It is pretty ugly bad on several levels. Essentially what the currrent behaviour does is, if the fill color has an transparency value, and draw some pixels, we just don't bother to write anything to the color surface at all, we only write to the alpha surface. (*) It is impossible to emulate efficiently when we switch to combined color+alpha surfaces (*) It works completely differently to how every other graphics API in the world operates (*) It makes no sense - it doesn't allow you to fill a shape with partially transparent color pixels (because it just doesn't bother writing to the color surface). This behaviour dates back to "initial import", so sadly no reason why. Noting that we are changing 3 things here: (1) Setting a fill color with transparency will actually write to the color surface. (2) Previously, SetFillColor(COL_TRANSPARENCY) was the same as SetFillColor(), now they mean different things (3) SetFillColor(x) where x has tranparency will now actually affect the fill color of the alpha layer. (4) VirtualDevice::SetOutputSizePixel will now erase/fill the device with data in cases where it previously would not (because previously the fill was ignored when background == COL_TRANSPARENT) Change-Id: I4c8b371a436a4d1ffc4344c7d6b21932d861397d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180184
Thanks Saburo
Cherry-picked commit to 25-8 as requested