Issue 50899

Summary: File contains deleted graphics
Product: Draw Reporter: wolframgarten
Component: uiAssignee: wolframgarten
Status: CLOSED FIXED QA Contact: issues@graphics <issues>
Severity: Trivial    
Priority: P3 CC: ace_dent, IngridvdM, issues
Version: 680m109Keywords: oooqa, regression
Target Milestone: 3.4.1   
Hardware: All   
OS: All   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---
Description Flags
bitmap still there none

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
Changed target
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.

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
Comment 11 clippka 2005-07-14 10:47:47 UTC
reassign to
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 16 kabban 2005-09-21 09:20:02 UTC
Created attachment 29746 [details]
bitmap still there
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
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

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.