Inkscape is changing CDATA section to &something; notation

[Petr Dlouhý]

When Inkscape is saving document, where is javascript with something between CDATA, like this:

<script type="text/javascript">
  //<![CDATA[
    document.write('something nasty<>&');
  //]]>
</script>

Then Inkscape will remove CDATA section and replace it with &something; notation like this:

<svg:script
  id="script2419">
  //
  document.write('something nasty&lt;&gt;&amp;');
//</svg:script>

The meaning is equivalent, but this behaviour is unpleasant, because it could make the script unreadable.

[franti (fhvill)]

Hello, sorry that I could not find your bug report and created a duplicate at https://bugs.launchpad.net/bugs/229359

This bug makes the script unreadable and indeed prevents it from running.

Amazingly I got this answer from sas to my original report at 229359:

<<<<<
It's correct behaviour for <![CDATA[ ... ]]> in the XML editor to change to &lt;![CDATA[ ... ]]&gt; in the file - the XML editor shows plain text, not escaped text, and text that you type into it will be interpreted as plain text, not as escaped text.

Likewise, " changing to &quot; is OK (though unnecessary for element content, as opposed to attribute values).
>>>>>

I am wondering what "normal behaviour" means! I claim that whichever way the script text one types or imports in Inkscape is interpreted, the sole concern should be that it works for the user when one comes out of Inkscape. This indeed is a bug.

If for any reason and for some people the text inside script tags should remain unescaped, that should be an option which can be turned on inside Preferences, escaped text being the default.

[MenTaLguY (mental-deactivatedaccount)]

sas is right. You shouldn't expect to be able to type <![CDATA[ ... ]]> into the text field and have it come out as real CDATA in the document, as that text field is interpreted as plain text (it's the unescaped contents of a text node) and not XML. If you typed SVG tags into the text field, you wouldn't expect that to create tags in the document either, would you? It's the same kind of thing.

For the sake of script readability, it would be reasonable for Inkscape to (for example) use CDATA as the preferred escaping method for the text content of particular tags like script, but you'll never see an option to disable both CDATA and &quot; type escaping so you can type in CDATA delimiters manually as text content -- that'd make it impossible for Inkscape to generate well-formed XML.

(Incidentally, the thing with putting Javascript comments on the CDATA delimiters isn't necessary in SVG, and shouldn't even be necessary in modern browsers.)

[MenTaLguY (mental-deactivatedaccount)]

(At least, the guard comments aren't going to be necessary in any XML-based language like XHTML or SVG. It's been a while since I've had to deal with the vagaries of regular HTML in this regard.)

[su_v (suv-lp)]

Reproduced with Inkscape 0.48.3.1,
no longer reproduced with current trunk (r11435): the embedded JavaScript is unchanged when saving the file in Inkscape.

Fixed in revision 10625 "Preserve CDATA sections on output."
<http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/10625>

[Philippe Joyez (ubuntu-5-pjoyez)]

CDATA are indeed restored when saving now.

However, when a python extension deep-copies and saves part of the tree where the CDATA structure should be, it is not retrieved in the output.

I see that the bug fix was to add the CDATA tag on output when the node type is XML_CDATA_SECTION_NODE. Is there a way to probe this node type in python, so that my extension adds the CDATA tag where adequate?