1. Create a new text document; 2. Format page style to have a custom bitmap as the area fill (use Add/Import in the Page Style dialog on tab Area in Bitmap mode) - make sure to apply; 3. Edit the page style again to remove the fill (set it to None) - this can be even done without closing the dialog at step 2, just after Apply button pressed; 4. Save the file, and inspect its contents using ZIP. The bitmap is inside the document, referenced from styles.xml's draw:fill-image element. There's no way to remove it; after reloading the document, the image is absent in the gallery on the Bitmap page of Area tab, thus one cannot delete it. Seems there was never a way to remove it; although the Area page changed over time, I couldn't quickly find a version where it allowed to remove the image from the document file. Tested with: Version: 6.4.2.2 (x64) Build ID: 4e471d8c02c9c90f512f7f9ead8875b57fcb1ec3 CPU threads: 12; OS: Windows 10.0 Build 18363; UI render: default; VCL: win; Locale: ru-RU (ru_RU); UI-Language: en-US Calc: CL Version: 7.0.0.0.alpha0+ (x64) Build ID: b29fb89d0a49fde0f5757774d64a7aba8298ac75 CPU threads: 12; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win; Locale: ru-RU (ru_RU); UI-Language: en-US Calc: CL Version: 5.0.4.1 (x64) Build ID: 2def61bcbb29a7a8611b833682fe1291910b11ad Locale: ru-RU (ru_RU) and OpenOffice.org 3.2.0 OOO320m12 (Build:9483).
I confirm it with Version: 7.0.0.0.alpha0+ (x64) Build ID: 5dcbd1bb557450a2d658a710c163b310c0cee157 CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win; Locale: de-DE (de_DE); UI-Language: en-GB Calc: CL
Version: 6.4.1.2 (x64) Build ID: 4d224e95b98b138af42a64d84056446d09082932 CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: default; VCL: win; Locale: en-GB (en_GB); UI-Language: en-GB Calc: threaded Confirmed with this version. 1. Create the default writer document. 2. Go to "Page Style (Default) > Area". Press "Bitmap", then press "Add/Import" and import a background image. Save it using the default dialogue box that pops up. Then press "Apply." EXPECTED RESULT: Icon should be accessible under "Bitmap" using the scrollbar. ACTUAL RESULT: Icon is not accessible. 3. Close dialogue and reopen. RESULT: The imported background is accessible again via scrollbar. 4. Close dialogue. Save, close then reopen file; then open dialogue again. RESULT: Background is inaccessible, and remains so permananetly. The same goes for any other backgrounds you import.
R. Green, you've changed bug summary, and AFAIK the expected result is now a bit different. Problem: Image is still part of the program, but you don't have access to it. Expected result in comment 0: LO should remove image from the program Expected result in comment 2: LO should make bitmap accessable for later use There should be a consensus about the expeted result. From a user perspective I tend to your expectation, R. Green. Mike, what do you think? Or have I misunderstood something?
(In reply to Dieter from comment #3) Well, comment 0 didn't declare that image should become removed automatically: strictly speaking, I only wrote that there's no way to remove it. Comment 2 indeed suggests the most obvious (and likely the only correct) way of solving the bug, so I also tend to agree with the edits :-) - however, the automatic removal of unreferenced images is also an option (inferior IMO).
Duplicate of bug 125969?
*** Bug 151177 has been marked as a duplicate of this bug. ***
I am reverting back to something similar to the original summary by Mike. The Comment 2 issue is more what's tracked in bug 125969, whereas this issue I think is best described with the steps below. Admittedly, both issues should be fixed in concert, but they are two different problems. 1. In a new file: Format > Page Style > Area > Image > Ass / Import an image, give it a name 2. Apply the image as background without closing the dialog 3. Change image background to one of the defaults, click Apply 4. Right-click the custom image in the collection, delete it 5. Save file and exit LO 6. Extract the ODT, look in Pictures directory Result: custom image is still there. Which in a way touches on the issue of privacy. Setting first version affected as 5.3 as that's when one could first add a custom image to the collection and use that "Delete" context menu command. Still reproduced in recent trunk build: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: e9a0c97de95688b2f86bbb4dd8c823af5442401c CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded
The removal of the image from the collection is irrelevant as to whether the image would/should remain in the ODT. Also irrelevant is whether or not it is a custom added image. Simplified steps to reproduce: 1.) In a new file, go to Format > Page Style > Area > Image. 2.) APPLY one of the pre-defined collection (without closing the dialog) 3.) Change image background to a different one in the collection; now click OK. 4.) Save file (as ODT) and exit LO. 5.) Extract the ODT, look in Pictures directory. Getting both images saved in the ODT started with a massive change in LO 4.4 with commit 7d9bb549d498d6beed2c4050c402d09643febdfa Author: Armin Le Grand on Tue Jul 1 13:30:09 2014 +0200 Related: #i124638# Second step of DrawingLayer FillAttributes... for Writer objects, now added support for Paragraph and PageStyle (including Header and Footer) for direct attributes and style attributes It is worth noting that the unnecessary picture is now dropped on the first round-trip, so relatively low importance. Probably the best code pointer is when that happened in LO 7.3 with commit 86c0f58b6f9f392865196606173d1b98a6897f32 Author: Michael Stahl on Wed Jul 14 19:50:18 2021 +0200 tdf#92796 ODF import: remove unused bitmap fills With CWS impress64 a partial fix for this was implemented to drop unreferenced named items including all non-color fills after ODF import, but this is only done in sd so move the code that does that to svx and call it from sc and sw as well. Implement some UNO interface for this, it's at least better than a magic string, and not obvious how a better solution would look like since it's known only at the end of the import if a bitmap is used or not. Another problem: when the Area tab is used to change to a different kind of fill, the items with the details for the previous fill aren't cleared, and so they are written to ODF files. Hence bitmaps in the file can be referenced even if they aren't actually used, and bloat up the files. Fix this by dropping all unused draw:fill-image-name attributes in ODF import. Also do the same for Gradient and Hatch fills; Transparency gradients can be combined with anything so leave them as they are.