Copying cloned objects between files fails

Originator: NO

You can copy cloned objects between files as long as copy the original
shape over too, but this only works if the original's ID is not already
taken in the destination document.

Confirmed in SVN. The paste creates a orphaned clone as the parent object is no longer in the document to be referenced. We need to either copy the original as well, or not create clones.

I find the most annoying part of this to be that I cannot copy clones _with their origin_ to a document where there already exists an object with the same id as the clone origin object id.

The solution, which to me seems rather simple, would be to change not just the ids of the copied objects, but also change the reference in the clone objects to point to the new id that the origin object just received.

related bugs, that either block or are blocked:

file open location
https://bugs.launchpad.net/inkscape/+bug/226782

xref svg files, linking to external files
https://bugs.launchpad.net/inkscape/+bug/171344

Child friendly version? (OLPC?)
https://bugs.launchpad.net/inkscape/+bug/170488

parity Amaya
one could provide a choice between a symbolic link, or copying the symbol into one's code.
however in general the first is to be preferred as it allows for easier maintenance, and lowers web traffic.
provided the resulting file is intended to be connected to the web, even intermittently.

Copying clones when the origin is in the <defs> part of the SVG file is an even more difficult side of this problem, the reason being that I cannot select the origin and move that along with the clone.

Jakob,

not sure how you are attempting this...

the natural or easy to understand route is similar to this:

open remote file eg: http://www.openicon.org/icon-ark/weather-icons.svgz

drag over, or select an icon, say 'sunny' edit, copy

open new document and paste.

in this way the only code cloned is:

<use xlink:href="http://www.openicon.org/icon-ark/weather-icons.svgz
#sunny" x="33%" y="72%" width="15%" height="30%" />

this has been known to work in Amaya.

> I cannot copy clones _with their origin_ to a document where there
> already exists an object with the same id as the clone origin object id.

This is fixed in SVN (see bug 165936).

As for fixing the original bug, we first need to decide what the correct behaviour is when clones are copied without the object they reference. Should we copy the referenced object anyway, and put it in 'defs' when we paste. Or should we just unlink the copied clones, so that they are no longer clones.

re: sas

as mentioned in my note above the better method is to reference the url, as there will be far less code copied around the web.
the user needs an option to copy the symbol or other <use> element in the case where this is not to be used on the web.

@peepo:

What URL?

If you mean a global URI, that situation never arises at present (we never have a global URI for the open document, as far as I know), so we don't need to worry about it yet.

If you mean a local URI (file:), then I don't think it's a good idea (at least, not as the default behaviour), as it would result in numerous complaints about broken files (due to the referenced file having been deleted or modified or moved or being on a different machine).

Of course, the source document may exist only in memory, in which case there is no URI at all.

sas,

some people always take a little longer to catch on.

the fact you never had a global URI is not a reason not to worry, nor for implementing something the 'wrong' way...
this has significant implications for the GUI, which may well have developed in a skewed direction, merely because this was never implemented.

Once you understand this much, it is then clear that each object should be a symbol and cloned, even if there is only one instance in the document.
that way someone else using a 'properly' instanced authoring tool, like inkscape will become... can reference the object without copying the code.

else they cant.

naturally if you dont understand this there are other issues to worry about such as the ones you suggest regarding skipping the cloning and copying the code instead. Or in your own words "unlink the copied clones, so that they are no longer clones."

that way no one can link to them, perhaps not the best move?

@peepo:

No, you've misunderstood how it works. See section 5.6 of the SVG spec.

re: sas,
what are you proposing is misunderstood? do you have a reduced test case?

I think different approaches to this may be useful to different
people, so this calls for a new user preference, to be placed on the
Clones tab:

When pasting a clone without its original into a new document:

- leave orphaned
- convert to a regular object (unlink)
- add the original to defs

bbyak,

undoubtedly that's a possibility, however one then needs to decide on the default behaviour, and ensure users are informed about their choices.

In explanation I'll add one reason for advising that every part should be created as a symbol, before being used.

Otherwise the repurposing is complex.
for instance the author may place the part off screen, for the current purpose.

There has been recent discussion in the SVGWG regarding issues such as why when gif and jpegs can be emebedded in an svg document with width and height specified etc, this cannot be done with SVG...
indeed!

but for the present it would be helpful if AT users and designers understood the benefits of creating symbols to a single standard size and scaling or transforming when used.

why aren't urls used in inkscape?

On Wed, Jul 16, 2008 at 12:08 PM, peepo <email address hidden> wrote:
> bbyak,
>
> undoubtedly that's a possibility, however one then needs to decide on
> the default behaviour

I think unlinking is the least surpriseful and thus the most
appropriate default behavior: it preserves appearance and does not
create invisible entities either in defs or on canvas.

--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org

Yes, I think for now unlinking is the best option.

to repeat:

why aren't urls used in inkscape?

what is the reason that one cannot open a remote svg such as

http://www.openicon.org/icon-ark/openclipart/colour/fruit.svgz#strawberry

or indeed these:
http://www.openicon.org/db/search.php?search=strawberry

So please tell me when this will be fixed ?

I also use a huge map and need to copy paste in a samller A4, parts of the map,
but the "used" rectangles or paths or so, are not copied because as is it said before the original is not copied !
I would expect to see in the new copy a unlinked object from the original file...

Please also note that this text field has bellow it a + button ADD an attachement and
another button Post comment (this second button is not show in Vista Home Premiun with IE8 but in Firefox is it shown corectly)

I agree that unlinking is the best option. Somebody suggested that a set of options be provided as to whether unlink, paste as is etc. But I am not able to imagine a use-case where an orphaned clone would be usefully pasted into a new document.

In bug 169120 (which I've marked a dup of this bug) someone reported that when an original+clone is being pasted if another object with the same ID as the original already exists, then there is a problem. This *might* be bug 165936 but I'm not sure (as that seems to talk about gradients which I don't grok too much about). Anyhow, I'm reposting my comments from bug 169120 regarding the policy to be following when copy-pasting clones:

When copy-pasting a set of objects where one is a clone, Inkscape should check to see whether the original of the clone is also being copy pasted.

1) If no, then Inkscape should unlink the clone and paste it.
2) If yes, then it should check to see whether an object with same ID as the original is already present.
2a) If yes, then it should rename the original being pasted and re-point the clone to the new ID.
2b) If no, then it should just paste the original and clone as is.

Note that when a set of objects is being copy-pasted, and one of them is a clone, it is not guaranteed that the original of the clone is also in the set of objects, hence the above checking procedure is required.

This bug is a huge usability problem. My humble request to the devels to fix this soon. Thanks.

@jamadagni I think you spell it out very well. These checks are precisely what I would also like to have.

Heh, thanks. This bug is nearing its 5-year anniversary (just 6 days left). WIll it receive attention?

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.

Committed in r14309, but needs testing