Description: If you set the background property to either an Impress or Draw document to color, and export to PNG, the top and left of the resulting exported PNG will have a 1px-wide white/blank gap. Steps to Reproduce: 1.Open either Draw or Impress (bug exists on both) 2.Set background color property to black (for ease of seeing the problem) 3.Export the page / slide as a PNG file Actual Results: On the resulting PNG image, the top and left sides of the image have a white or blank gap on them approximately 1 pixel wide. Expected Results: The entire PNG should be black (or other selected background color) with no white gap on the top and left of the image. Reproducible: Always User Profile Reset: No Additional Info: User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36 OPR/52.0.2871.64
I should have added that this happens when the margins of the document are set to 0, 0, 0, 0
no repro with draw Version: 6.0.5.0.0+ Build ID: d1407aac59f3f218a311452fc7dcb7692fdf5285 CPU threads: 8; OS: Linux 4.14; UI render: default; VCL: kde4; Locale: nl-BE (en_US.UTF-8); Calc: group
Repro, but only on Windows. Version: 6.1.0.0.alpha0+ Build ID: 104b26b246c94c8c66864b20d00e419d96b15961 CPU threads: 4; OS: Windows 10.0; UI render: default; TinderBox: Win-x86@39, Branch:master, Time: 2018-04-16_08:30:15 Locale: fi-FI (fi_FI); Calc: group Arch Linux 64-bit Version: 6.1.0.0.alpha0+ Build ID: 14184060bd2249a492ea44d36463914c421e6ce5 CPU threads: 8; OS: Linux 4.16; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on April 23rd 2018
Already in 4.3.0, but not in 3.5.0. Not sure, if this can be bibisected.
Ugh! This bug still exists in 6.1.3.1. It forces me after exporting a PNG file from LO Draw to then go into yet another editing tool to clean up the export because the top and left area of the export are not covered by the background color. Huge time waster.
Created attachment 145811 [details] Export PNG sample from LO 6.1.3.1 This is a sample of what the bug does to a file. Look at the top and left extreme edges. This occurs when the margins of the draw document are set to None, and I have to go into each and every export in another program (paint.net) and clean it up.
(In reply to Buovjaga from comment #4) > Already in 4.3.0, but not in 3.5.0. Not sure, if this can be bibisected. Windows only has bibisect repo starting with 4.4, therefore I'd say no.
(In reply to Aron Budea from comment #7) > (In reply to Buovjaga from comment #4) > > Already in 4.3.0, but not in 3.5.0. Not sure, if this can be bibisected. > Windows only has bibisect repo starting with 4.4, therefore I'd say no. Does that mean it can never be fixed?
(In reply to mwtjunkmail from comment #8) > Does that mean it can never be fixed? No, it just means the causing commit can't be easily identified (bibisecting is a method to do that, for details see [1]). [1] https://wiki.documentfoundation.org/QA/Bibisect
Version: 6.2.0.1 (x64) still broken. PNG export still has white line top and left.
If both the height and width of a given page in Draw are set to exact multiples of 96 DPI, the lines do not appear. For example, 10.00" wide and 9.40" inches high produces a page that is 960 x 902 pixels and does not result in white lines top and left. Setting a document's proportions to fractions of inches that do not subsequently result in a full multiple of 96 dpi will create the white lines, either top and left or both. This is still an error. Gravit Designer, Paint.net, and other programs permit any dimension to be set on a document, resulting in something other than a full multiple of 96 DPI, without producing such a white line top and left.
Still broken in Version: 6.2.0.2 (x64)
TIFF wasn't affected by this but LibreOffice_6.2.1.1_Win_x64 now has TIFFs messed up with this bug as well.
Just switched to PNG in LibreOffice_6.2.1.1_Win_x64 and that seems to be working. I really wish I knew what was causing this.
(In reply to mwtjunkmail from comment #14) > Just switched to PNG in LibreOffice_6.2.1.1_Win_x64 and that seems to be > working. I really wish I knew what was causing this. Nope, I can still repro with PNG Arch Linux 64-bit Version: 6.3.0.0.alpha0+ Build ID: 1663b1e8233db6c6d1c2b35639ad984961084009 CPU threads: 8; OS: Linux 4.20; UI render: default; VCL: gtk3; Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US Calc: threaded Built on 26 February 2019
Hmm, weird - in the past we could not repro on Linux!
Just thinking out loud here. Could it be tied to printer settings? Setting the printer to print to PDF versus a physical printer or something? I'm currently set to print to microsoft PDF versus my physical printer (I'm out of ink and my output is for screen only anyway).
(In reply to mwtjunkmail from comment #17) > Just thinking out loud here. > > Could it be tied to printer settings? Setting the printer to print to PDF > versus a physical printer or something? I'm currently set to print to > microsoft PDF versus my physical printer (I'm out of ink and my output is > for screen only anyway). I don't believe the File - Export... code path has anything to do with printer settings.
Now we have a 4.2-4.3 bibisect repo for Win, but unfortunately the bug is already in the oldest commit.
With much fiddling, I've discovered that at least with PNG exports, this setup https://imgur.com/HaHwEzc eliminates the lines. Turn off Save Transparency and turn on Interlaced mode the lines go away.
I'm going crazy. I don't know what I did to an existing document to fix it, and it didn't take all that long to fix it, and after fiddling with another new document and paying attention to every step, could not get rid of the white line. I've attached my testing steps.
Created attachment 151122 [details] LO Testing 5/1/2019 did not isolate bug
(In reply to mwtjunkmail from comment #22) > Created attachment 151122 [details] > LO Testing 5/1/2019 did not isolate bug Contents of this text file: Ok, I started from scratch since results are still inconsistent. This is driving me crazy. 1. Created a new LO Draw Version: 6.2.3.2 (x64) 2. Selected View, Master 3. Selected Page, Properties 4. On the Background tab of Page Setup, selected Color and Black from the HTML pallete 5. Selected Page, Properties again and set the Margins to 0,0,0,0 7. Exported to PNG leaving the defaults (Interlaced and Save transparency checked, compression 1) Results: Got the 1-pixel wide white line top and bottom of the exported PNG. 8. Exported to PNG again, delselecting the Save transparency option but leaving the Interlaced option checked. Results: Still got white line 9. Exported to PNG again, delselecting both Interlaced and Save transparency options. Results: Still got white line 10. Selected View, Normal 11. Exported to PNG again, delselecting both Interlaced and Save transparency options. Results: Still got white line 12. Exported to PNG again, selecting both Interlaced and Save transparency options. Results: Still got white line 13. Selected the Page Properties button from the Properties Panel 14. Left all options alone except deselected Master Objects Results: Still got white line 15. Deselected Master Background 16. Set the Background option to Color 17. Selected Color and Black from the HTML pallete At this point: Format = Letter, Orientation = Portrait, Background = color Color = Black, Margin = None, Master Page: Default Master Background = deselected Master Objects = deselected I noticed with master background selected and background = black that having a white page meant the background color was for the master not the individual page. 18. I re-selected Master Background 19. Exported to PNG again, selecting both Interlaced and Save transparency options. Results: Still got white line 20. Exported to PNG again, leaving Interlaced selected and deselecting Save transparency Results: Still got white line 21. Saved the file. 22. Exported to PNG again, leaving Interlaced selected and deselecting Save transparency Results: Still got white line 23. Selected Page, Properties 24. Selected the Transparency Tab. Default was No Transparency. 25. Selected the Transparency option and set it to 0% 26. Hit OK 27. Exported to PNG again, selecting both Interlaced and Save transparency options. Results: Still got white line 28. Selected Page, Properties 29. Selected Fit object to paper format 30. Exported to PNG again, selecting both Interlaced and Save transparency options. Results: Still got white line
It's not a white line. It's a line of nothing. I pulled up some PNG exports in paint.net and noticed hashed squares. That's the alpha channel only that's rendering. If you select the alpha channel not to render, to get a gray line. Either way -- alpha only or gray line -- to the naked eye it looks like a white line. It's almost as if one programmer long ago decided the origin of a picture to start rendering an export was (0,0) and then someone else came along later and assumed pictures start rendering at point (1,1).
In: Version: 7.0.0.0.beta2 (x64) Build ID: 1c213561a365b5666167321de68c9977500c9612 CPU threads: 8; OS: Windows 10.0 Build 20152; UI render: default; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL Bug does not happen with Skia set as the rendering service. However, Skia has its own set of problems in other regards, so I'm still using hardware rendering, which still causes the bug. There is a hardware rendering workaround: If I apply a 10x10 pixel black bitmap as each slide's background, the white line top and left goes away. It's a harmless enough kludge, and I've been doing it for months now so I can keep functioning while this bug waits to get addressed. Ideally, regardless if using Skia or hardware rendering, I should be able to set each slide's background to black color (or whatever color I want) and be done with it.
Still happening in: Version: 7.1.0.0.alpha0+ (x64) Build ID: df74aef7159d7155addf78cfc4d139485945d794 CPU threads: 8; OS: Windows 10.0 Build 20236; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded I changed the title of this bug because it's not a white line. It looks white using Microsoft Windows Photos but I bring it into paint.net and I see that it's really just a 1-pixel region top and left that has not been rendered (it's alpha only). I'm thinking all you need to do to fix this bug when the background is set to a color is start the color flood fill on the background to coordinates 0,0 instead of 1,1 and you're done.
For every conceivable combination using: Version: 7.2.0.0.alpha0+ (x64) Build ID: f313e27fb7f2d42247407e26e16f264e30f87ca5 CPU threads: 8; OS: Windows 10.0 Build 20262; UI render: default; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded --- Works fine for me using Skia Rendering/AA --- Still a problem with Hardware Rendering/AA
Still a problem in this configuration: Version: 7.2.0.0.alpha1 (x64) / LibreOffice Community Build ID: 94c1521be4ef12f195d08413d5e2134e07a49f85 CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: default; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL
I was not able to reproduce this in: Version: 7.5.3.2 (X86_64) / LibreOffice Community Build ID: 9f56dff12ba03b9acd7730a5a481eea045e468f3 CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded - - - I followed Steps 1-7 in Comment #23. Then: - File > Export > PNG and there was no 1px transparency. Even with: - various checkboxes - + flipping between Normal/Master - + No / 0% Transparency none of the PNGs I produced had 1px transparency. - - - Perhaps this bug can also be made easier to reproduce if: - A problematic ODG file is attached. - - - **Side Note:** This may have also been preemptively solved in Bug #126319: - 7.4.0 - 7.3.2 where Armin Le Grand fixed bitmap export. Similarly, there was a lot of extra "1 pixel lines" being generated along various edges of PNGs.
Created attachment 187197 [details] Screenshot from GIMP zoomed in 12800% Look what I see in GIMP. Bottom and right edge. Arch Linux 64-bit, X11 Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: b1568a4cd8b439de19aab2bfe5f8f8465e4dc6af CPU threads: 8; OS: Linux 6.3; UI render: default; VCL: kf5 (cairo+xcb) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Built on 10 May 2023
No repro with 7.3.0.3 nor: Version: 7.6.7.2 (X86_64) / LibreOffice Community Build ID: dd47e4b30cb7dab30588d6c79c651f218165e3c5 CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: kf5 (cairo+xcb) Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: CL threaded Even tried to change display scaling just in case.
Not reproducing now in Version: 24.8.0.1 (X86_64) / LibreOffice Community Build ID: 6fd6cae02baed1e82d14ed2da1f2458092354dab CPU threads: 24; OS: Windows 11 X86_64 (10.0 build 22631); UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded