Open mspanish opened 10 years ago
You can also see the extra SVG created by the svg.import.js - I understand that will be fixed by using the much anticipated svg.adopt.js :)
Caramba esto ya me tiene media loca!
I've put way more console.log() statements together in svg.import.js than I'd care to admit, and I have yet to see why this script would be changing my parent g element's id to that. For attr.id, I get the correct id in the various places I can check that - and while I see clearly in svg.js where the id is created - I don't see why it's setting that id on that element, which already has an id that theoretically should be passed.
So I'm gonna sleep on this! I wouldn't be bothering if it weren't crucial to this script I'm working on - it's one I didn't write originally, and looks like in the end I may need to rewrite how that SVG is getting originally created to avoid all of the g nesting when I can.
I've been running some tests and I am unable to reproduce it. Id's always get transferred correctly.
Where you're mentioning attr.id
I'm assuming you mean attr('id')
?
Ah yes sorry, I do mean attr('id). You know I figured out that my coloring problems have nothing to do with these couple of id's that aren't transferring right - in fact, the svg.import.js is doing a fantastic job, and the image gets reproduced perfectly, and it appears all paths and attributes are editable.
As for the id's would you like me to attach one of my SVGs to check out?
Yes, I'll have a look.
Hello this is continued from here:
https://github.com/wout/svg.import.js/issues/17
My SVG code is generated by svg.js - then I export the files as .svg. I am then using svg.import.js to import them back in so you can re-edit saved characters you've made.
The problem is with g groups. While the child g elements all have the correct id's needed for character editing, the parent g elements used for grouping body parts together get incorrectly parsed by the importer, and their g ids get replaced by a dynamically generated id.
For example:
Becomes: