Comment 24 for bug 167907

Revision history for this message
David Mathog (mathog) wrote :

This bug is now over 7 years old and is still around!

This is a pretty tricky problem "to do right". To "do it right" I think there is no option but a complete defs to defs comparison between the two files, which would produce an ID to ID map for both directions. The logic is not complex

defs1 -> each entry to unique form becoming Key with bidirectional links to current ID
defs2 -> each entry to unique form becoming Key with bidirectional links to current ID
sort keys from defs1
sort keys from defs2
produce map from merge of keys1 with keys2

but the first step, generating the unique key, is tricky. The only sure way to determine if the two ObjectA's are the same is to compare the keys, which might be just the SVG string from the object. But there are all sorts of minor differences that might make a strict compare come out negative when they are the same. For instance, lines can be in different orders in the SVG, and within style, elements can be in any order, default values might be used explicitly or omitted. So the SVG for each object needs to be taken apart, all of its pieces placed in the correct order, cases adjusted, all default values entered or omitted, and then and only then will the key be comparable to another.

If we give up on doing it right, though, there is a simpler trick that should suffice for this sort of case:

File 1:
ObjectA
ObjectB (Uses ObjectA)

File2:
ObjectA (used by some object that doesn't matter for this discussion)

We have to decide when to copy (and rename) ObjectA from File 1. Certainly on the first copy of something that references it should always be copied, since we have no intent of comparing objects, but what about when we copy ObjectC that also uses ObjectA? Surely we wouldn't want to make yet another duplicate.

Here is one possible solution. It is not ideal, in that it will in many cases produce extra copies, but at least all copies between documents will be complete.

1. Generate a unique session ID each time Inkscape runs (a UUID, for instance).
2. When ObjectB is copied to file2 inkscape changes the <use> link to ObjectA_UUID. Inkscape looks in file2 for that object. It does not find it, so it copies ObjectA to ObjectA_UUID
3. When ObjectC is copied inkscape again changes the <use> link, looks for the new ID. This time it finds it and so only copies ObjectC.

After a couple of rounds of this, and copying back and forth between files, one might end up with objects with IDs like ObjectA_UUID1_UUID1_UUID2_UUID3. That would be ugly, but at least the copies would still work, which is what the end users care about.