If i use Inkscape for adjusting 1 thing, i want the SVG code of only that 1 thing to change, not have lots of my SVG code changed just because of some internal representation or convenience for the Inkscape implementors.
If it's just one thing, perhaps you will have no problem writing a simple script to change it? So that you never again have to touch the evil Inkscape?
Inkscape is not evil, it's really, really nice. Great work done. I'm promoting its use. For a designer i guess it's great even, for a SVGcoder it needs serious changes.
-------------------
If i use Inkscape for adjusting 1 thing, i want the SVG code of only that 1 thing to change, not have lots of my SVG code changed just because of some internal representation or convenience for the Inkscape implementors.
So basically what you like to see is this:
Inkscape opens/imports your SVG document, makes an internal representation of it. You do some editing. And want to apply the modified objects to the text structure found in your old document.
That sounds like it indeed.
Inkscape keeps a score for 'modified', elements, uses something like libxml to parse the tree and modifies a specific tag/id pair. After that, writes it out in layer sequence. Now this may sound stupid, but your 'textual' (visual) reprentation will change if a library reads it in, makes a structure out of it, and writes it out in a specific manner.
I understand the "internal representation" story. I just believe it could be improved.
Probably you don't like inkscape because it adds all possible attributes to the code and it becomes unreadable. But I find it rather interesting how you would like to determe if a change changes only the imported attributes or it should add more attributes because a shape is modified.
I do like Inkscape (i promote it even), i just think it could be even way better. Maybe something like this could (partially) work: Within the internal representation have "absent" as an option for attributes. And also a variable called "notation" with as possible values "attribute" and "style". And maybe under "save as" a "coder preferences" thing that is collapsed/hidden on default with all sorts of options, for example "What do you prefer? style or attributes?", "no default value code", "everything an id", etc.
ps. this almost sounds like a 'MS Word' HTML-export discussion. Probably the only thing that is asked is the output to be clean as plain-svg.
It's the plain-svg i care about indeed. When a program does what i want it to i don't care much about it's internal representation.
------------------------
Inkscape is implemented as if things that render the same (or just similar even) are the same too, thereby destroying clean code. Which is wrong and makes it near useless for coders, heavily frustrating the number 1 strong point of SVG: letting coders and clickers cooperate.
If i use Inkscape for adjusting 1 thing, i want the SVG code of only that 1 thing to change, not have lots of my SVG code changed just because of some internal representation or convenience for the Inkscape implementors.
4 lines together visually forming a square, is not the same as a real
square.
A name/value attribute pair can sometimes by SVG specification be replaced with some CSS, but even that makes a difference in semantics. And with SVG support usually being partial, it often also makes a difference in rendering.
I believe what you think are bad intentions might actually be a minor bug.
I don't think it are bad intentions. I think it is an aspect (earlier?) overlooked or underestimated in importance.
We strive to save SVG as correctly as possible, but the correctness is in SVG-as-an-image, not SVG-as-a-document. However, we are working on a new SVG-DOM package, which we hope will improve things greatly. I am the guy working on the DOM document stuff, and I also have an interest in saving SVG similarly to how it is loaded. Javascript animating SVG is the reason I got into the Inkscape project myself.
That's great, thanks. Good luck with that work.
Ruud (stelt)