Apache OpenOffice (AOO) Bugzilla – Issue 50899
File contains deleted graphics
Last modified: 2017-05-20 10:31:02 UTC
Open the sent bugdoc, delete the polygon and the background bitmap under format/page/background so that the page is totally empty. After saving the apparently empty doc a few times the saved data still contains the graphics.
*** Issue 50903 has been marked as a duplicate of this issue. ***
Please, add a button or macro, which deletes all bitmaps in a selected odg file safely. My odg files are getting bigger an bigger with every change. And I'm not the only one having this problem. It is even a security and privacy risc, because you can easily make images public without even knowing it. Thanks, Kabban.
Changed target
*** Issue 51796 has been marked as a duplicate of this issue. ***
Please, integrate the fix into 2.0. And please give us users clue to rescue all the drawings with the obsolete bitmaps inside. Thank You very much!
There is no fix yet and it is a bit risky to do late fixes in that area since OOo 2.0 is already in final stages. The issue exists only for fill bitmaps, not graphic shapes, so the security risk is minimal as fill bitmaps normaly doen't contain contents. This issue also happens with other 'named items' like gradients, hatches, line ends and transp. gradients This issue was introduced as a sideeffect when AW removed the drawing layer undo pool. The 'named items' of itemsets in undo are now also exported. On load, 'named items' introduced by the styles.xml are not removed during document lifetime, so they are exported again and again and again even if not used. The whole concept of 'named items' needs a complete rework here. This caused trouble since release 3.0 of StarDraw (which later was named StarImpress). For OOo 2.0.1 I can think of a fix that removes the unused items after a second safe. Not writting unused items at all would require a more sofisticated fix. One idee is to iterate over all objects in the document before save.That could be a performance impact. I have to evaluate this further
"Not writting unused items at all would require a more sofisticated fix. One idee is to iterate over all objects in the document before save." Can't you add an hidden option in the saving menu: which would ask me: "do you want to save bitmap 1, 2, 3, ... yes or no?" regardless of beeing used or not? I create maps with large and changing background bitmaps. The draw files are getting so big now, that OO isn't able to let me work with the files anymore. (cpu jumps to 100% and stays there.)
I managed to make a riskless fix that removes unused items after reload and save. I will try to bring this into OOo 2.0 but it is on risk. I added some 'fake' calls to the removeByName methods of the named item containers from SdXMLFilter::Import() to remove unused items. It is dirty but it works.
Thank You! I'll go thru every draw file an my HD und test it, as soon as the next version is available and report back.
kabban, the fix currently is only in the childworkspace impress64 wich is now in our internal qa and will be integrated into OOo 2.0 as soon as it has clearance. This means this fix may not in the next build but should be in the following. re-open issue and reassign to wg@openoffice.org
reassign to wg@openoffice.org
reset resolution to FIXED
Verified in CWS.
Tested in master m119. Closed.
case not totaly fixed. Please, look at my new file. I can't delete the bitmap in the picture folder.
Created attachment 29746 [details] bitmap still there
Reopened.
Reproducible. Please have another look.
No surprises, but confirming still a problem in DEV300m10 WinXP. This is actually a regression (added keyword) from Issue 7795, and as such I respectfully ask for the target milestone to be reviewed. Many thanks Andrew
*** Issue 24224 has been marked as a duplicate of this issue. ***
The new report is actually a different issue. The problem now is that the page had previously a bitmap filling as a background. when switching to a color fill bitmap we still keep the fill bitmap set at the page and this causes it to be exported. cl->cl: 1. Fix the removal of fill bitmaps if the fill style is set to any other fill style (also for hatches and gradients) 2. Do not export this attribute if fill style is not fill bitmap (again, also for hatches and gradients)
cl->cl: also investigate issue 24224 which in my opinion is no duplicate
I fixed that assigning a slide background to a slide or master page with a different filling than the previous removes unused gradients, bitmaps and hatches. I also implemented that whenever a shape gets a new fill style set, it also remove unused gradients, bitmaps and hatches. This fixes the issue that in calc the are fillings are also not vanishing. This fixes part of issue 24224. I can't fix that documents already containing unused page fillings are repaired automatically. I tried some possibilities but all increased load time which is not what we want. But such documents should not be possible to create again. Documents can be repaired by switching the page backgrounds to something else and back. (changeset 69091b8fc77c) fixed in cws impress210 for OOo 3.4
verified in cws, back to qa