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
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.
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: 188.8.131.52
Build ID: 2c39ebcf046445232b798108aa8a7e7d89552ea8
Import button also disappeared in LO 4.4.5...
oops... sorry, please disregard comment #3
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: 184.108.40.206
> Build ID: 2c39ebcf046445232b798108aa8a7e7d89552ea8
> Locale: fi_FI
That was reported as bug 93041 and has been resolved for 5.0.1 and master.
*** Bug 96927 has been marked as a duplicate of this bug. ***
In LibreOffice 3.3.0, the background image, when no longer used, is removed from the file.
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.
Created attachment 121904 [details]
image shows results of ODF validation with the file that has the bug.
invalid ODF ... Major?
Reproducible with LibreOffice 3.5.0 Build ID: d6cde02
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.
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.
*** Bug 95955 has been marked as a duplicate of this bug. ***
This problem still exists in Writer 220.127.116.11 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.
** Please read this message in its entirety before responding **
To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.
There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.
If you have time, please do the following:
Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/
If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.
Please DO NOT
Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not
appropriate in this case)
If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/
2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword
Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!
(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
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 :-( )
This problem still exists in Writer 18.104.22.168 on LinuxMint 19.2-64.
This bug is still present in:
Build ID: 983db96a17630be906b868d2be811663f0d846f6
CPU threads: 12; OS: Linux 4.4; UI render: default; VCL: x11
Locale: en-US (C.UTF-8); UI: en-US