Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||File contains deleted graphics|
|Status:||CLOSED FIXED||QA Contact:||issues@graphics <issues>|
|Priority:||P3||CC:||ace_dent, IngridvdM, issues|
|Issue Type:||DEFECT||Latest Confirmation in:||---|
Description wolframgarten 2005-06-17 12:08:38 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.
Comment 1 wolframgarten 2005-06-17 12:43:30 UTC
*** Issue 50903 has been marked as a duplicate of this issue. ***
Comment 2 kabban 2005-06-19 12:58:18 UTC
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.
Comment 3 clippka 2005-07-11 09:52:32 UTC
Comment 4 wolframgarten 2005-07-11 10:02:34 UTC
*** Issue 51796 has been marked as a duplicate of this issue. ***
Comment 5 kabban 2005-07-11 10:06:10 UTC
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!
Comment 6 clippka 2005-07-11 14:53:13 UTC
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
Comment 7 kabban 2005-07-11 19:07:11 UTC
"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.)
Comment 8 clippka 2005-07-13 18:41:10 UTC
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.
Comment 9 kabban 2005-07-14 09:59:51 UTC
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.
Comment 10 clippka 2005-07-14 10:47:38 UTC
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 email@example.com
Comment 12 clippka 2005-07-14 10:47:51 UTC
reset resolution to FIXED
Comment 13 wolframgarten 2005-07-14 11:27:09 UTC
Verified in CWS.
Comment 14 wolframgarten 2005-07-19 12:59:15 UTC
Tested in master m119. Closed.
Comment 15 kabban 2005-09-21 09:19:03 UTC
case not totaly fixed. Please, look at my new file. I can't delete the bitmap in the picture folder.
Comment 17 wolframgarten 2005-09-21 09:31:35 UTC
Comment 18 wolframgarten 2005-09-21 09:32:27 UTC
Reproducible. Please have another look.
Comment 19 ace_dent 2008-04-27 21:02:20 UTC
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
Comment 20 IngridvdM 2010-12-08 10:55:07 UTC
*** Issue 24224 has been marked as a duplicate of this issue. ***
Comment 21 clippka 2011-02-10 09:43:34 UTC
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)
Comment 22 clippka 2011-02-10 09:44:51 UTC
cl->cl: also investigate issue 24224 which in my opinion is no duplicate
Comment 23 clippka 2011-03-04 20:32:13 UTC
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
Comment 24 clippka 2011-03-29 12:49:26 UTC
verified in cws, back to qa
Comment 25 wolframgarten 2011-03-31 10:32:11 UTC
Verified in CWS.