Download it now!
Bug 131438 - Imported backgrounds cannot be accessed using the scrollbar in the Bitmap gallery
Summary: Imported backgrounds cannot be accessed using the scrollbar in the Bitmap gal...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Area-Fill-Tab-Bitmap
  Show dependency treegraph
 
Reported: 2020-03-20 10:21 UTC by Mike Kaganski
Modified: 2020-12-07 10:47 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Kaganski 2020-03-20 10:21:07 UTC
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).
Comment 1 Dieter 2020-03-25 18:19:02 UTC
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
Comment 2 R. Green 2020-03-29 16:27:44 UTC
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.
Comment 3 Dieter 2020-03-30 10:04:27 UTC
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?
Comment 4 Mike Kaganski 2020-03-30 10:18:07 UTC
(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).
Comment 5 Heiko Tietze 2020-12-07 10:47:33 UTC
Duplicate of bug 125969?