Bug Hunting Session
Bug 92796 - [ODF] Writer does not remove unused page background image/bitmap
Summary: [ODF] Writer does not remove unused page background image/bitmap
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.5.0 release
Hardware: Other All
: medium major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: preBibisect, regression
: 95955 96927 (view as bug list)
Depends on:
Blocks: ODF-export-invalid
  Show dependency treegraph
 
Reported: 2015-07-17 01:41 UTC by Olivier Hallot
Modified: 2019-08-21 21:53 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
This file has a lost image in a style not rechable anymore (334.39 KB, application/vnd.oasis.opendocument.text)
2015-07-17 01:41 UTC, Olivier Hallot
Details
image shows results of ODF validation with the file that has the bug. (521.04 KB, image/png)
2016-01-13 18:22 UTC, Olivier Hallot
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Olivier Hallot 2015-07-17 01:41:02 UTC
Created attachment 117287 [details]
This file has a lost image in a style not rechable anymore

Step to reproduce:

On a blank text document, define a page style and get a large image to put as bitmap backgound in the Area tab of the page style.

Apply plage style and save file. 

Check and note the size of the stored document.

open file back and image should be there.

Edit the page style and set bitmap to blank
(NOte: It s not obvious to remove a backgroup bitmap to the "blank" entry, if that is the way to do).

click ok, then page has now a blank background.

Save file, check file size

File has same size, large bitmap was not deleted.

Anoterh issue: If you delete your custom page style and let it reset to default page style, the file size does not shirnk. Image is still stored in the file bu unreachable.

The attached document has an image that I can't access anymore thru LibreOffice
Comment 1 Olivier Hallot 2015-07-21 18:15:40 UTC
Actually if you add an image background to page and later change the background to a color, the ODT file keep your image background and you have no way in the UI to remove it.
Comment 2 Buovjaga 2015-07-30 17:56:32 UTC
Confirmed, unzipping the odt you will find the image in Pictures folder.

Btw. there is no Import graphic button in 5.1..

Win 7 Pro 64-bit, Version: 4.4.4.3
Build ID: 2c39ebcf046445232b798108aa8a7e7d89552ea8
Locale: fi_FI
Comment 3 Olivier Hallot 2015-07-30 19:56:19 UTC Comment hidden (off-topic)
Comment 4 Olivier Hallot 2015-07-30 19:57:20 UTC Comment hidden (off-topic)
Comment 5 V Stuart Foote 2015-08-09 14:19:50 UTC
Verifying that changes to page background do not clear unused bitmaps/graphics. 

Additionally, the unused images remain referenced with <draw:fill-image/> stanzas in the styles.xml for the ODF archive when document is saved and reopened.

Shouldn't the reference be cleared from the style?

(In reply to Beluga from comment #2)
> Confirmed, unzipping the odt you will find the image in Pictures folder.
> 
> Btw. there is no Import graphic button in 5.1..
> 
> Win 7 Pro 64-bit, Version: 4.4.4.3
> Build ID: 2c39ebcf046445232b798108aa8a7e7d89552ea8
> Locale: fi_FI

That was reported as bug 93041 and has been resolved for 5.0.1 and master.
Comment 6 Buovjaga 2016-01-06 19:21:22 UTC
*** Bug 96927 has been marked as a duplicate of this bug. ***
Comment 7 Cor Nouws 2016-01-08 11:21:52 UTC
In LibreOffice 3.3.0, the background image, when no longer used, is removed from the file.
Comment 8 Olivier Hallot 2016-01-13 18:20:56 UTC
because of this bug, the file is not compliant to ODF 1.2 according to ODF Validator in http://odf-validator.rhcloud.com/

The image attached is the result of the validation. Note the <draw:fill> error.
Comment 9 Olivier Hallot 2016-01-13 18:22:30 UTC
Created attachment 121904 [details]
image shows results of ODF validation with the file that has the bug.
Comment 10 Cor Nouws 2016-01-13 18:58:32 UTC
invalid ODF ... Major?
Comment 11 raal 2016-01-17 21:10:39 UTC
Reproducible with LibreOffice 3.5.0 Build ID: d6cde02
Comment 12 Dave Koelmeyer 2016-03-01 23:04:59 UTC
Serious bug due to unnecessarily inflated file sizes in storage-critical corporate scenarios. 

Also related: loading styles into a target blank document from an existing document with page styles containing background images, and in the "Load Styles..." dialogue explicitly omitting page styles from being loaded, still results in source document's page style images being loaded into the target document anyway. The page styles are not loaded, but the embedded images used in them *are*.

This makes hard manual work of retrospectively replacing certain page style background images to (for example) a document template, when a bunch of other custom styles have been added over time.

If anyone has a reproducible workaround for this I'd love to hear it.
Comment 13 Caolán McNamara 2016-07-19 22:45:28 UTC
caolanm->dtardon: you fixed something that sounds quite like this, but for impress. I imagine b876bbe2cacce8af379b10d82da6c7e7d229b361 makes no difference to writer, but intriguing in similarity.
Comment 14 Cor Nouws 2016-09-05 14:57:28 UTC
*** Bug 95955 has been marked as a duplicate of this bug. ***
Comment 15 Pongtawat 2017-05-05 03:52:14 UTC
This problem still exists in Writer 5.2.6.2 on Debian.

If I manually edit style.xml to remove the line referencing the old file, once save by Writer, the old file will be removed automatically.
Comment 16 QA Administrators 2018-05-06 02:30:05 UTC Comment hidden (obsolete)
Comment 17 Buovjaga 2018-06-27 16:17:26 UTC
(In reply to raal from comment #11)
> Reproducible with LibreOffice 3.5.0 Build ID: d6cde02

preBibisect because this commit is the first in our bibisect repos
Comment 18 ajlittoz 2019-01-24 14:58:41 UTC
Unaware of this bug report, I investigated on this incorrect behaviour after a question on the French leg of AskLibO.

I experimented with .fodt files. From my analysis, the culprit could be in the page style definition (section <office:automatic-styles> in the XML). The modified page style is described by an XML element <style:page-layout style:name="pm1"> (of course, the exact name does not matter).

Initially, we have attribute draw:fill="none".

When we add a background image, the attribute turns to draw:fill="bitmap" with tons of additional attributes to describe image placement and repetition. A draw:fill-image-name="xxx" is also created with the image data stored in section <office:styles> as a record <draw:fill-image draw:name="xxx"> with binary image data.

First question: why is binary image data duplicated in <style:page-layout style:name="pm1"> ? Since there is reference to the image store, this duplication prevents image sharing and contributes to file size inflation.

Then I reverted to no brackground. Attribute draw:fill is correctly reverted to value "none". Binary image data is deleted BUT draw:fill-image-name="xxx" is kept!

If there is a reference counter in the image store, this counter can't go to zero and this could be the reason why the image remains in the store.

Second question: why is attribute draw:fill-image-name not deleted when we choose another background then bitmap?

I then tried to remove manually the image from the UI. In the Area tab of the page style dialog, bitmap mode, i clicked on the image in the left pane to select it. I right-clicked the selected image and chose Delete from the menu. The image is no longer displayed in the pane, even after exiting and reloading, but it is still present in the image store.

I thought of forcing value of draw:fill-image-name to some other value. For that, I set the background image to some of the gallery. This effectively changed the value of the attribute, I deleted the image and reverted to None afterwards. Now, there are 2 images in the store: my custom one and the one chosen from the gallery, both unreachable.

If you can make profit of this information … (I'm no developper :-( )
Comment 19 Grantler 2019-08-21 21:53:22 UTC
This problem still exists in Writer 6.3.0.4 on LinuxMint 19.2-64.