I am using Inkscape 0.48 (on Mac OS X under X11) to create resources for a video game. A feature I am making heavy use of is the ability to add custom attributes to the XML elements within the SVG document-- I have defined a bunch of attributes like polycode:density="" which are meaningless to Inkscape but my game code knows how to interpret, and I add them to the document using Inkscape's "xml editor" window. This works fine but I am having a problem.

Some of my custom attributes contain very long blocks of multiline text, specifically they contain scripts written in Lua. What I find is that Inkscape allows me to put multi-line text into an xml attribute; and I can save as many times as I want, and the multi-line text remains multi-line; but when I *open* a svg document in Inkscape, at that time all multi-line xml attributes in the entire document get collapsed down to single lines, and the next time I save all of my xml attributes are single line. This is extremely inconvenient, it confuses my source control and also it could break my code at some point.

Why is Inkscape doing this, and how do I make it stop?

What I've tried so far: I tried setting an xml:space=preserve attribute on the toplevel svg:svg element in the effected document, but this did not help, it did things to the whitespace * between * elements and broke the display in the XML Editor window, but it did not change Inkscape's behavior wrt whitespace in attributes.

Previously, I had a problem where at the same point in time that Inkscape is now eating my whitespace (document open), it was also stripping my custom polycode: namespace prefixes. I eventually fixed this by adding a xmlns:polycode="http://msm.runhello.com/local/svg/polycode0" attribute to the top of each document containing polycode: attributes. (The URL listed is not a valid URL, it's a 404.) Looking on the internet, I got the impression that if I can get Inkscape to load a "DTD" for my polycode: namespace, I can mark in the DTD that the attributes for which I do NOT want whitespace eaten are "CDATA" and this is supposed to make Inkscape leave those attributes alone. However, the document explaining this also suggested xml parsers like Inkscape should assume any attribute they do not recognize to be CDATA. Will creating a DTD solve my whitespace problems? How do I get Inkscape to load the DTD? And are there any examples of Inkscape-compatible DTDs of this sort out there, since I do not have experience with DTDs?

Thanks all.

mcc wrote:Why is Inkscape doing this,

XML attribute-value normalization. It converts all newlines to spaces.

mcc wrote:and how do I make it stop?

I don't think you can. It's done by the XML processor, and all XML processors are required to do it.

Have you considered storing the code as element content rather than attribute values? You could then reference it from attributes.

Hmm, okay. However something I notice. Although the spec does say inline newlines should be collapsed, the spec ALSO says that character entities for newlines like 
 or 
. My "real" problem here is I write an attribute containing newlines, I close and reopen the document, and my attribute is not the way I saved it, it's spaces now. So if that is what the XML spec says, then I think my real complaint is, shouldn't Inkscape be *saving* newlines as 
 / 
, so they will be unpacked the way I originally saved them? Is there a way to make it do this?

Let's say I'm desperate enough for this functionality I'm willing to do something like write a plugin or write a patch to Inkscape myself... what would be the best way to do this? Do you think if I were to file a "bug" on Launchpad requesting %#xA; newlines on save, it would be taken seriously? Is downloading the Inkscape code from launchpad probably my best bet...?

sas wrote:Have you considered storing the code as element content rather than attribute values? You could then reference it from attributes.

This would be inconvenient for a couple of reasons. I'm using these attributes in a way analogous to html event handlers and so there might be several such handlers on a single object (onCollide="", onClick="", etc).

I guess the "correct" way to do this, or the way I'd do this if i were writing DHTML anyway, would be to put my newline-ful blocks at the top as a <script></script>, define functions, and then later say like onCollide="ballCollided()" ... hm

mcc wrote:I think my real complaint is, shouldn't Inkscape be *saving* newlines as &#10; / &#xA;, so they will be unpacked the way I originally saved them?

In theory maybe; but newlines in attribute values aren't needed in SVG, and there's a potential to cause problems for normal usage, so I doubt it's a good idea.

Is there a way to make it do this?

I don't think so.

Let's say I'm desperate enough for this functionality I'm willing to do something like write a plugin or write a patch to Inkscape myself... what would be the best way to do this?

Inkscape has no real plug-in support, so it would have to be a patch. If you're serious about this, you should ask on the Inkscape developers' mailing list to see what they think. I'm not sure they'll like it though.

I guess the "correct" way to do this, or the way I'd do this if i were writing DHTML anyway, would be to put my newline-ful blocks at the top as a <script></script>, define functions, and then later say like onCollide="ballCollided()" ... hm

This seems like the best approach.

Inkscape 0.91 r13725 - Inkscape deletes " " (spaces) apparently at random between letters in text on save (apparently, as sometimes spaces disappear after I re-open the file).

Reporting it here because it seems possibly related.