Bug 117160 - Solid color background on Impress and Draw leaves top and left 1px-wide alpha (unrendered) when exporting to PNG
Summary: Solid color background on Impress and Draw leaves top and left 1px-wide alpha...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
4.2.0.4 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: preBibisect, regression
Depends on:
Blocks: Graphics-Export
  Show dependency treegraph
 
Reported: 2018-04-22 15:41 UTC by xordevoreaux
Modified: 2024-07-16 20:02 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Export PNG sample from LO 6.1.3.1 (20.96 KB, image/png)
2018-10-18 19:23 UTC, xordevoreaux
Details
LO Testing 5/1/2019 did not isolate bug (2.61 KB, text/plain)
2019-05-01 22:37 UTC, xordevoreaux
Details
Screenshot from GIMP zoomed in 12800% (5.11 KB, image/png)
2023-05-11 11:08 UTC, Buovjaga
Details

Note You need to log in before you can comment on or make changes to this bug.
Description xordevoreaux 2018-04-22 15:41:11 UTC
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
Comment 1 xordevoreaux 2018-04-23 02:01:22 UTC
I should have added that this happens when the margins of the document are set to 0, 0, 0, 0
Comment 2 Xavier Van Wijmeersch 2018-04-23 12:24:05 UTC
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
Comment 3 Buovjaga 2018-04-23 13:06:29 UTC
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
Comment 4 Buovjaga 2018-04-23 13:11:24 UTC
Already in 4.3.0, but not in 3.5.0. Not sure, if this can be bibisected.
Comment 5 xordevoreaux 2018-10-18 19:20:27 UTC
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.
Comment 6 xordevoreaux 2018-10-18 19:23:55 UTC
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.
Comment 7 Aron Budea 2018-11-07 22:35:04 UTC
(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.
Comment 8 xordevoreaux 2018-11-21 03:17:08 UTC
(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?
Comment 9 Aron Budea 2018-11-21 04:57:35 UTC
(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
Comment 10 xordevoreaux 2018-12-21 21:33:16 UTC
Version: 6.2.0.1 (x64) still broken. PNG export still has white line top and left.
Comment 11 xordevoreaux 2019-01-06 14:43:45 UTC
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.
Comment 12 xordevoreaux 2019-01-10 16:24:55 UTC
Still broken in Version: 6.2.0.2 (x64)
Comment 13 xordevoreaux 2019-02-27 13:27:01 UTC
TIFF wasn't affected by this but LibreOffice_6.2.1.1_Win_x64 now has TIFFs messed up with this bug as well.
Comment 14 xordevoreaux 2019-02-27 13:32:41 UTC
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.
Comment 15 Buovjaga 2019-02-27 17:49:17 UTC
(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
Comment 16 Buovjaga 2019-02-27 17:50:27 UTC
Hmm, weird - in the past we could not repro on Linux!
Comment 17 xordevoreaux 2019-02-28 04:35:05 UTC
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).
Comment 18 Buovjaga 2019-02-28 07:26:35 UTC
(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.
Comment 19 Buovjaga 2019-04-15 15:54:03 UTC
Now we have a 4.2-4.3 bibisect repo for Win, but unfortunately the bug is already in the oldest commit.
Comment 20 xordevoreaux 2019-05-01 03:16:59 UTC
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.
Comment 21 xordevoreaux 2019-05-01 22:36:36 UTC
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.
Comment 22 xordevoreaux 2019-05-01 22:37:38 UTC
Created attachment 151122 [details]
LO Testing 5/1/2019 did not isolate bug
Comment 23 Buovjaga 2019-05-02 07:19:45 UTC
(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
Comment 24 xordevoreaux 2019-05-04 02:59:54 UTC
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).
Comment 25 xordevoreaux 2020-06-28 11:59:37 UTC
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.
Comment 26 xordevoreaux 2020-10-16 11:38:34 UTC
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.
Comment 27 xordevoreaux 2020-11-23 17:29:33 UTC
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
Comment 28 xordevoreaux 2021-05-25 02:46:16 UTC
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
Comment 29 Tex2002ans 2023-05-10 21:18:54 UTC
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.
Comment 30 Buovjaga 2023-05-11 11:08:45 UTC
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
Comment 31 Stéphane Guillou (stragu) 2024-06-05 15:12:39 UTC
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.
Comment 32 xordevoreaux 2024-07-16 20:02:07 UTC
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