My use case: I'm trying to write a drawing to be overlaid on top of a web page with a dark colour scheme. Hence I'm developing with a black background.
However setting this background prevents exporting as transparency. It exports a black background.
Therefore my export process is "remove background, export, put background back" .. doing this regularly is quite burdensome.
It would be nice if an option were available to ignore the background (and just make it transparent) when exporting, so that this extra hassle could be avoided.
(An alternative implementation would be to be able to set the window's colour - so that the page background and the overall background could be changed independently).
Thanks for reporting!
This is a legit enhancement request. Therefore I mark this as NEW.
I don't think implementing an option to discard page background on image export (but only for image formats that handle transparency) is the correct way to go about solving your problem. It adds extra complexity/clutter to the dialogs for an option that can be handled properly using other work-arounds mentioned below.
LO's image export is already extremely confusing, inconsistent, and buggy. While attempting to reproduce the original behavior, I discovered that pngs behave differently than gifs! I'm testing in LO 4.4.1, but in LO 4.0, the png export dialog didn't even have a "save transparency" option, so I'm assuming this was originally reported when exporting gifs?
As far as I know, there is no way to have LibreOffice export an entire page as png with a transparent background. Even if you leave the page background color set to "none," it will always export the png with the background color.
With pngs, the only way to get draw to actually honor the save transparency setting is to only export a selection. When I do it that way, LO does honor my request and only exports my selected item and will make the background transparent as expected.
When exporting the entire page as a gif with page background set to "none," the resulting image does, in fact, have a transparent background. The exported image bounds are wrong and extend from the start of the paragraph region in the top left to the end of the page region in the bottom right, but I guess that is another bug. But the export does mostly what we would expect.
If we export the entire page with page background set to black, it does export the background as black, as originally reported. I see this as the intended and expected behavior.
I can think of two easy work-arounds to the originally reported issue:
1. Select all of the items you want to export, and check the box for "Selection" in the File->Export dialog. In LO 4.4.1, this is checked automatically whenever you perform File-Export while you have an active selection. Even if you have a page background, exporting just the selected objects will create an image with a transparent background. This also works for exporting pngs.
2. If exporting a full page (not just selection) gif, temporarily simply set your "Document Background" color to be black. (Tools->Options->LibreOffice->Appearance). This is the alternative the original poster mentioned. Again, this will not currently work if you're exporting a full page as png, since it never honors your request for transparent background.
Also, draw's image export behavior needs to be fixed to properly handle layer properties as described in bug 53864. You could then create a locked black background layer and mark it "visible" but "non-printable."
I tested this behavior using LO 22.214.171.124 and 126.96.36.199 using 32bit Fedora 17.
From what I can tell, this affects all exports.
When I wrote this bug report (2 years ago, almost to the day!), I was exporting GIF because PNG transparency has always been flaky. (You seem to have figured out how that works better than I ever did).
Nowadays, I export SVG diagrams as well. Same problem.
You're right, setting the page background to be a dark colour exports that colour - this is what I'd expect it to do.
Perhaps I didn't explain the use case for my feature request (it's not a bug) properly.
I am drawing an image, which will later appear on a web site with a darkish background colour scheme. So some of the lines in my drawing are white, to match the colour scheme of the web page they will appear on. Unfortunately, while the page background is set to "none", the page actually appears in the editor as white. Therefore my white lines are effectively invisible while editing.
Perhaps a better fix than the one I came up 2 years ago, would be to have the Format/Page/Background/Fill/"none" option allow you to choose a colour to view the page as while editing, so that "none" doesn't have to mean "but we'll show you a white background". That would also mean no changes to exporting are needed. (The PNG export bug is an entirely unrelated issue).
Having transparency for the page background sounds not reasonable to me, neither to tweak other settings. So my suggestion is that you add a special shape for the background, place it on an extra layer, and we introduce an option to not export this layer, just like the printable option. Meanwhile you could easily cut/paste back this object for the export, which would be faster than going to the page settings.
(In reply to grotlek from comment #3)
> Perhaps a better fix than the one I came up 2 years ago, would be to have
> the Format/Page/Background/Fill/"none" option allow you to choose a colour
> to view the page as while editing, so that "none" doesn't have to mean "but
> we'll show you a white background".
You can actually do that - go into
Options -> Application Colors and set Document background to your preferred dark color.
(In reply to Tomaz Vajngerl from comment #5)
> You can actually do that - go into
> Options -> Application Colors and set Document background to your preferred
> dark color.
Export to PDF saves the background color, to SVG doesn't. Despite this inconsistency I think an extra layer property for export/print would be a nice solution.
Cleaning up old tickets. There are several workarounds to deal with page background (Tolls > Options, layer, export of selection) and in agreement with c2 I resolve this request as WFM. Thanks for reporting and sorry for the delayed decision.