First -- I'd like to take the opportunity to thank you for Inkscape... Truly an important application to have as open source.
I am one of the matplotlib developers, and somewhat recently extended its SVG output backend to save the glyph outlines directly in the SVG file. (To remove the need to install obscure math fonts everywhere the SVG file will be viewed.) It uses <defs>/<symbol> to define the character and then <use> to render them. Yes, SVG fonts would probably be better for this, but the lack of support for them in Mozilla and other tools makes them a no-go for now.
One of our users recently came across a problem where copying from one SVG file into another mangles the text. See his blog here:
http://assorted-experience.blogspot.com/2008/03/inkscape-matplotlibs-svg-one...
From poking around the resulting XML, what seems to be happening is that the <symbol> elements in the pasted data are reassigned new ids, but the <use> elements are not updated accordingly, and thus the <use> elements end up referring to symbols in the existing (pasted onto) file. Matplotlib, at present, assigns ids to glyph outlines sequentially as they are encountered, so there is no attempt to assign "universally" unique names, and id clashes across different files are guaranteed.
There's a simple workaround I'm considering at our end, which is to use hashes on the path content itself as ids. This would also ensure that glyphs that are common between files will have the same id, for whatever that's worth. It does seem to at least make things behave as expected in Inkscape.
However, I wanted to bring this to your attention because
a) maybe this is an Inkscape bug, and it should be correcting the defs/use links on a copy/paste operation.
b) maybe my understanding/expectations aren't correct and I'm just horribly misusing the SVG spec...
I've attached two example SVG files. If you open both, and then copy the contents of one into the other, you can see that the title text will be incorrect.
Cheers, Mike
On Wed, Mar 26, 2008 at 11:18 AM, Michael Droettboom <mdroe@...1923...> wrote:
a) maybe this is an Inkscape bug, and it should be correcting the defs/use links on a copy/paste operation.
Exactly. Confusion of IDs of referenced elements on copy/paste is a long-standing Inkscape problem.
Mental: as I remember you mentioned that to fix this, we need to have the clipboard as an SPDocument. This has just been done on trunk :) What's the next step?
On Wed, 26 Mar 2008 12:51:05 -0300, "bulia byak" <buliabyak@...400...> wrote:
Mental: as I remember you mentioned that to fix this, we need to have the clipboard as an SPDocument. This has just been done on trunk :)
Yes. XML::Nodes don't know anything about hrefs to be able to update them, but SPObjects do.
What's the next step?
It depends a bit on the architecture of the new clipboard code, which I haven't looked at in much detail yet.
Chris, what do you think?
-mental
MenTaLguY wrote:
On Wed, 26 Mar 2008 12:51:05 -0300, "bulia byak" <buliabyak@...400...> wrote:
Mental: as I remember you mentioned that to fix this, we need to have the clipboard as an SPDocument. This has just been done on trunk :)
Yes. XML::Nodes don't know anything about hrefs to be able to update them, but SPObjects do.
What's the next step?
It depends a bit on the architecture of the new clipboard code, which I haven't looked at in much detail yet.
Chris, what do you think?
-mental
I was concerned by the id conflict problem too (in fact, I was hit by it several times when editing Gartoon icons). The problem is that while finding a new unique id when pasting a def is easy, there is no easy way to change all the references in the document to a given ID. At present the only ways I can think of to do this from the clipboard code would be: a) iterate over all the items in the SPObjects and all its attributes and CSS properties that can refer to other objects, and replace mentions of the modified ID. b) do a text search/replace over a string containing the XML. Actually I think b) would work much better, because a) is prone to omissions. I'll try to pull off this hack shortly so that we have a fully working clipboard. The right way would be to do what is proposed in this roadmap item:
Create an SPObject API for tracking references and avoiding id clashes on import and interdocument copy/paste. What we need are a void SPDocument::importCopies([set of SPObjects]), and an [set of SPObjects] SPObject::dependencies() method.
The only problem with this roadmap item is that it omits an important point - there is little problem in obtaining the dependencies of a given object, and this is what _copyUsedDefs() in current clipboard code does (however, it checks all the possible ways a def can be referenced, which isn't optimal either). The problem is getting the dependent objects of a given def. Therefore the above interface has to be extended with a third method like auto_ptr<std::list<SPObject*> > SPObject::dependentObjects(). Implementing this thoroughly would mean modifying or at least checking all the code that creates or removes defs from the document. However, everything the clipboard needs is to have this data valid just after it is loaded from the file. I don't have a complete public API proposition ready yet, much less a clear idea of how should this be implemented, but generally both dependencies and dependents should be tracked.
Regards, Krzysztof (Chris) Kosiński
participants (4)
-
bulia byak -
Krzysztof Kosiński -
MenTaLguY -
Michael Droettboom