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: 4.4.4.3 Build ID: 2c39ebcf046445232b798108aa8a7e7d89552ea8 Locale: fi_FI
Import button also disappeared in LO 4.4.5... -> Bug
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: 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.
*** 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 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.
** 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! Warm Regards, QA Team MassPing-UntouchedBug
(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 6.3.0.4 on LinuxMint 19.2-64.
This bug is still present in: Version: 7.0.0.0.alpha1+ Build ID: 983db96a17630be906b868d2be811663f0d846f6 CPU threads: 12; OS: Linux 4.4; UI render: default; VCL: x11 Locale: en-US (C.UTF-8); UI: en-US Calc: threaded
ODF is OK, the "draw:fill" problem is solved in the meantime. So I have removed block 108198. The problem is, that the image is still referenced in the style, although draw:fill="none" is set. Same happens with a previously set fill color, only that has no such effect on file size. Tested with Version: 7.1.0.0.alpha0+ (x64) Build ID: 1e0cfd5662d95cea84e80e4fe10d52c3b1101ae6 CPU threads: 8; OS: Windows 10.0 Build 18362; UI render: Skia/Vulkan; VCL: win Locale: de-DE (en_US); UI: en-US Calc: CL
The bug may seriously afflict privacy!
Is there any plan to fix this problem?, I have a documento of about 200kb occuping more than 1MB because this. Also some deleted images appears as hidden and is a problem to remove it...
This is probably true for every case where a bitmap can be specified. Confirmed for paragraph background, footer background, frame/textbox background. Seems NOT to be true for section background. (Note that I cannot even see the image in the section background, so the visual aspect is broken! However, it does save it, but then when the background is changed to colour instead, the picture not saved and even removed from the file.) [Section uses the old "background" tab instead of the "Area" tab, so it probably uses RES_BACKGROUND instead of XATTR_FILLBITMAP.]
(In reply to Caolán McNamara from comment #13) > 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. Yes, it sounds like it will take a master programmer to handle this. The very existence of the Graphic seems to means it gets a styles.xml entry like <office:styles> <draw:fill-image draw:name="my_big_picture" xlink:href="Pictures/xyz.jpg" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad"/> I tried "cancelling" the bitmap when selecting none with _pSet->Put( XFillBitmapItem(OUString("bogus"), Graphic()) ); but that didn't help (and for some reason, an empty string did even less).
*** Bug 119100 has been marked as a duplicate of this bug. ***
Hello, Still present and annoying in version Version: 7.1.2.2 / LibreOffice Community Build ID: 10(Build:2) CPU threads: 12; OS: Linux 5.10; UI render: default; VCL: kf5 Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR 7.1.2-2 Calc: threaded Tested with background image in page style ... If you try several successive images as background ... all of them stay in Pictures subfolder inside the odt.... The only way to suppress them is to unzip the odt, suppress the pictures in Pictures subfolder , fiddle with styles.xml and zip the whole files to have the new .odt. It would be great to have "something" in the ui to deal with these hidden images
Michael Stahl committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/86c0f58b6f9f392865196606173d1b98a6897f32 tdf#92796 ODF import: remove unused bitmap fills It will be available in 7.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
these will now be removed on ODF import
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-7-2": https://git.libreoffice.org/core/commit/6511448b408887811f5026ccdd1b170e3731afd8 tdf#92796 ODF import: remove unused bitmap fills It will be available in 7.2.0.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Verified. Fixed. Thanks for this fix. 334 kb before opening the file 8 kb after saving with Version: 7.2.0.1.0+ (x64) / LibreOffice Community Build ID: a4360b155bef02cf3da41e3f05c56d42feef7926 CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: ro-RO (ro_RO); UI: en-US Calc: threaded