If there is an existing method for making a copy of an SPDocument, what is it called?
Resolving bug 1318657, without introducing other problems, seems to require that the clipboard be replicated, and all actions occur on the replica, which is then thrown away. See comments 8 and 9
https://bugs.launchpad.net/inkscape/+bug/1318657
Thanks,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
On Fri, 2014-05-30 at 17:40 -0700, mathog wrote:
If there is an existing method for making a copy of an SPDocument, what is it called?
I wrote one a few months back fixing a command line bug/feature, but ended up not using it. My investigations then and now don't show anything and it's hard problem from what I remember.
Does anyone else know of a clone/duplicate document feature? If not there should be one in the SPDocument interface so I would encourage it's addition.
Martin,
On Sat, 31 May 2014, Martin Owens wrote:
On Fri, 2014-05-30 at 17:40 -0700, mathog wrote:
If there is an existing method for making a copy of an SPDocument, what is it called?
I wrote one a few months back fixing a command line bug/feature, but ended up not using it. My investigations then and now don't show anything and it's hard problem from what I remember.
OK.
Bug 1318657 could probably be resolved by another route, with a more extensive rewrite. Currently it looks for duplicate defs between the target dcoument and the clipboard, and fixes these by modifying the clipboard version. Unfortunately that is a permanent change to the clipboard which can result in erroneous behavior if it is then pasted into a different window. As things are currently written the simplest way around this is to make a copy of the clipboard (an SPDocument), operate on it, copy that into the target document, and then throw out the copy. Except we apparently do not have a way to make that copy!
It occurs to me that another method to accomplish this would be to detect all the duplicates in the clipboard, create from that a list of defs to drop and a list of references to convert, and then essentially edit a copy of the XML of the clipboard to introduce those changes. Then push that edited copy of the XML in as if through "import", but this time skipping all the checks for duplicates. I don't know if there is a duplicate() method for an XML tree (as I am not at my development machine), but presumably that should be a much simpler function to write than SPDocument's duplicate().
One other matter related to this same bug - is there anything in the SVG spec that says the sorts of things normally stored in <defs> must be stored there? The current "look for duplicate swatches" code doesn't look anywhere outside of defs, so it will not work properly if those pieces are not there. Who knows how many other places in Inkscape make the same assumption. It should be easy enough, if not super efficient, to have the duplicate search code look for things that should be in <defs> elsewhere in the SVG and move them into the modified XML's <defs> before the actual import. If all the "import" and "paste" paths do this consistently then elsewhere in Inkscape it would then be safe to only check defs for the things that should be in defs.
Regards,
David Mathog
participants (3)
-
David Mathog -
Martin Owens -
mathog