vacuum defs slightly broken

[Amphi-users]

Sometimes vacuum defs doesn't remove all unused defs at once. Eg if you run
it twice, it sometimes is still able to remove unused defs on the second
pass, which clearly shouldn't be the case. (Observed with 0.45 on Win2k)

It also doesn't always delete all unused defs. No matter how often you run
it. (Observed with 0.45 to SVN 0705051800 on Win2k)

Creating a test case appears to be rather difficult. After saving, closing
and opening it was able to remove the 2 unused defs, which it couldn't
delete earlier. This is somewhat puzzling.

[Amphi-users (amphi-users)]

Originator: YES

Save and reopen isn't actually necessary. Saving the file is enough for
being able to remove unused leftover defs.

[Bug Importer (bug-importer)]

This is probably not going to be possible to fix until NRArenaShape etc.
are decoupled from SPStyle.

-mental

[ScislaC (scislac)]

This problem is pretty bad now. Priority is being bumped up because this is a bad regression.

If an example file is needed, I will post it (it's not on this machine). But, when working on my About Screen submission for 0.46, my filesize exploded when I was testing filters and such. Vacuumed defs, saved, all that jazz... still bloated. Then I just selected all and pasted to a new document... saved the new document and the filesize was almost half.

[sas (sas-sas)]

ScislaC, if this bug is still present, could you (or someone else) please post an example file?

[amphi (i-launchpad-kaioa-com)]

See the last paragraph of the initial post. You can't really create a test case, because vacuum defs will work as intended (usually, that is) once you saved it.

[sas (sas-sas)]

I saw what you wrote in the original post - but ScislaC offered to post an example file, and must therefore believe that's possible. Perhaps ScislaC's problem isn't exactly the same as yours, but it's likely that they are closely related.

[ScislaC (scislac)]

I will see what I can do about checking to see if the problem still exists later tonight, and if it still does I'll provide the example file I mentioned.

[Krzysztof Kosinski (tweenk)]

The problem still exists. Using --vacuum-defs from the command line works well though.

[Maximilian Albert (cilix)]

Can someone who sees this provide a bit more information as to what kinds of elements in the defs are removed/not removed? This might help to track the problem down.

[Jon Ellis (ellis-jon)]

Why won't vacuum defs remove unused Start/Mid/End Markers? I have a ton in the "commonly used section" which aren't actually used. I want those removed.

[David Mathog (mathog)]

Start with the attached svg file. In Inkscape select everything and delete it. Vacuum defs. Save. The SVG defs section will contain a large number of Gradient and Pattern entries.

0.48.2 on XP SP3.

[David Mathog (mathog)]

Note that these leftover defs can be removed by doing

Vaccum defs
Save

a second time.

[David Mathog (mathog)]

One other observation:

Open in Inkscape the example I posted, save as EMF call it one.emf.
Do "vacuum defs" and save (again as emf), call it two.emf.

There are some slight differences between one.emf and two. emf.

1. The words "join" and "cap" on the top right part of the image overlap in two.emf.
2. All the circles (and partial circles) are very slightly different sizes.

These pretty much by definition must be bugs since "vacuum defs" is only supposed to affect unused definitions.

[David Mathog (mathog)]

Yet another observation - uniconvertor 1.1.5 will not read the initial SVG, blowing up with

   Parsing error: at least 2 colors required

run vacuum def, save (twice) and then uniconvertor 1.1.5 can read it.

[David Mathog (mathog)]

The uniconvertor built into Inkscape 0.48.2 also gives the "2 colors required" message when saving to WMF, even after running multiple cycles of "vacuum defs" and "save', as does the command line uniconvertor 1.1.5. There is something toxic to uniconvertor in the defs section of this file which is used by one or more of the image elements. Reduced this complex svg down to just a single circle and a line of text, and it was still toxic. Note the extra defs which will not go away. Only be eliminating every single visible element could I get rid of the extra defs.

[David Mathog (mathog)]

Or not. This one I cannot remove the few remaining defs, even though there is nothing left in the file!

[su_v (suv-lp)]

> residual defs even after multiple vacuum save cycles

Those are intentional (not a bug): they are custom color swatches (osb:paint="solid") which never should be removed with 'Vacuum Defs', even if currently not referenced by any object.

[su_v (suv-lp)]

<off-topic>
> The uniconvertor built into Inkscape 0.48.2

UniConvertor is not built into Inkscape - it is an independent project which - for the convenience of Windows users - is bundled and installed together with Inkscape on Windows. The UniConvertor project is currently undergoing a complete rewrite and will not provide any bug fixes for the latest release (1.1.5) which is bundled with Inkscape 0.48.2.
</off-topic>

> This one I cannot remove the few remaining defs.

You created those yourself by converting fill (or stroke) colors into custom swatches. They can be deleted in the context menu of the color swatches of the 'Auto' palette (per document defined color palette):
<http://wiki.inkscape.org/wiki/index.php/Release_notes/0.48#Custom_Swatches>
<http://tavmjong.free.fr/INKSCAPE/MANUAL/html/Attributes-Fill-Stroke.html#Attributes-CustomSwatches>

(See also bug #594445)

[David Mathog (mathog)]

I cannot delete them from this document inside Inkscape. When I open toxic2.svg the "fill and stroke" window has everything grayed out. Cannot select the swatch option. There are no objects left in the document, and so no path to the swatches. To get around that created one object (a rectangle, ir probably didn't matter what it was) and then swatches were listed. However the manual says to delete them:

To delete a swatch, select Delete from the menu that pops up when you Right Click on the swatch in the Palette or Swatches dialog (the Auto palette must be selected).

There is nothing I can see in the fil and stroke dialog marked as "auto pallete", and right click is ignored every place I tried it: on the swatch icon, on a swatch entry in the pull down list, and on every other location. Ten minutes of manual spelunking later I found shift-ctrl-W, that puts up the actual swatches dialog, which is not the same as clicking on the swatches icon in the "fill and stroke" dialog. From the swatches dialog swatches could be deleted - but only from the swatches dialog! They remained in the document. When I then saved the file they were still visible in the SVG (via a text editor). Reopened it in inkscape, opened the swatches dialog, right click on the big X and select "convert" - it still lists all the swatches which I had tried to delete, even though there is only the big X in the swatches dialog. These can also be seen in the XML editor (which I just discovered), but editing the XML directly is not something a typical user should ever need to do.

Also I never intentionally created any swatches, until you mentioned the term I was unaware of it. The swatches listed are all called gradients, but every one of them in this case is a solid color.

I can see where swatches would be useful for some people, but for me it is just one more complication that makes what I am trying to do harder. Any chance we can have a "disable swatches" switch? Along similar lines, disable opacity and disable gradients would also be very useful. Swatches, opacity, and gradients are all features which I need to avoid, and yet they keep getting set by accident. Hmm, come to think of it, the list of features which might be beneficially disabled is pretty long: Patterns, filled open paths. Certainly there are others. All of these cause problems going through another program or file type, and have to be avoided in the inkscape drawing if the ultimate target is something other than an inkscape drawing.

(Note, I do not get to choose the ultimate target in this case, the people I am supporting are going to use powerpoint or whatever no matter what I say, so I have to get from inkscape to their chosen format.)

[Martin Owens (doctormo)]

The bug required STR (steps to reproduce) which will probably include creating objects in a new document, deleting those objects with different defs and attempting to clean the defs. Once we have the steps, then this bug can be pinned.

[insaner (insaner)]

perhaps related to bug #1177888 and bug #594445

[David Turner (novalis)]

FWIW: On trunk, I tried running "clean up document" (hereinafter, "vacuum defs") on the example from comment #11. It seems to remove everything except the defs which have the osb:paint attribute. The vacuum defs code doesn't seem to have really changed since at least 2006. But there might be callees that have changed. I also tried running vacuum defs on the examples from #15; the only remaining defs are those with osb:paint and two non-orphan defs. Re #13, I just tried it; there was no difference in the two images. The two emf files did differ (by 4 bytes in size), but when I rendered both images to png, they were byte-for-byte identical.

Is this still a live issue?

[Kris (kris-degussem)]

Closing report by lack of feedback and instructions ti invoke the issue.
Please revert bug status if this is done in error.