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.
Cheers,
On 6/14/06, Ruud Steltenpool <svg@...705...> wrote:
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?
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)
On Jun 14, 2006, at 8:38 PM, bulia byak wrote:
On 6/14/06, Ruud Steltenpool <svg@...705...> wrote:
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?
To be fair, this complaint is actually a feature request asking for "roundtripping" like a lot of HTML editors, and at least one XML editor have. And to be fair to Inkscape, the vast majority don't offer this feature and Inkscape produces very readable, if verbose, output.
As I understand it, a roundtripping XML editor (like Xopus) first performs an initial XSL transformation that marks each element with a reference back to the source document so that subsequent transformations can be reverted back in part, if not in whole. It's actually an interesting abstract problem that may have a more general solution.
David
bulia byak wrote:
On 6/14/06, Ruud Steltenpool <svg@...705...> wrote:
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?
If that 'one thing' is to line up a number of generated objects in a visually appealing fashion, or adjust a colour to be more in keeping with the document as a whole, then it wouldn't really be possible without a visual interface. If it's not inkscape's mission to fulfil that role then what SVG editor is?
I routinely use inkscape to superimpose objects in useful positions above generated SVG content, and the quality of the XML output is of interest to me. Though I do appreciate, and regularly use, inkscape as the best OSS vector graphics app around, the way I first found it was as an SVG tool.
John
On Fri, 16 Jun 2006 17:26:07 +0100, John Pybus <john@...368...> wrote:
If that 'one thing' is to line up a number of generated objects in a visually appealing fashion, or adjust a colour to be more in keeping with the document as a whole, then it wouldn't really be possible without a visual interface. If it's not inkscape's mission to fulfil that role then what SVG editor is?
Speaking as the person who's probably had the most influence on Inkscape's XML code at this point, I'm certainly interested in roundtripping, but it really is difficult. At the moment I'm simply working on getting full roundtripping at the XML Infoset level. We'd need that at least before even thinking about lexical (or byte-level) roundtripping.
Two other issues do need to be considered:
1. At what point does roundtripping become an aesthetic rather than a technical consideration? We already roundtrip essentially all of the portions of Infoset required to correctly implement the Namespaces in XML and SVG standards (though we're still more agressive about changing things in the document than we need to be).
2. At what point would the additional overhead required for roundtripping become unacceptable? We already get complaints about our memory usage -- would all the extra annotations required for lexical roundtripping be worth it?
-mental
On Thu, 15 Jun 2006, Ruud Steltenpool wrote:
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.
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.
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.
Yours Sincerely,
Stefan de Konink
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.
On Thu, 15 Jun 2006, Ruud Steltenpool wrote:
Date: Thu, 15 Jun 2006 01:00:02 +0200 (CEST) From: Ruud Steltenpool <svg@...705...> To: inkscape-devel@lists.sourceforge.net Subject: [Inkscape-devel] Inkscape 'breaks' SVG
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.
I asked about round tripping SVG before but suffice to say there is a lot of infrastructure work needed to make that possible. All we can do is wait patiently or try and contribute patches to help make it happen.
In such cases I still use Jasc Webdraw (limited but it did a great job of preserving concise clean markup) or a plain text editor.
Inkscape has a long way to go before it will be suitable for the kind of preservation of the underlying SVG which would be very useful for programmers.
If you were to use CVS diff on your files you might be able to isolate and limit the changes to your existing files but I agree with you it isn't something Inkscape was designed for and isn't currently well suited to that kind of thing. Inkscape is a great tool and useful for many things but isn't perfect for every job or all ways of working - at least not yet ;) - I hope no one claimed otherwise.
Using the XML Editor might allow you to make changes without there being quite so many knock on effects to your underlying markup.
Thanks for using Inkscape
-- Alan H.
participants (7)
-
Alan Horkan -
bulia byak -
David Himelright -
John Pybus -
MenTaLguY -
Ruud Steltenpool -
Stefan de Konink