Don't have time this AM to try the test case, but I'm seeing a similar situation where a SVGZ saved in some unknown version of Inkscape (file metadata does say 0.46), using an imported PDF, contains character 0001s that the parser doesn't like with a fresh install of Inkscape 0.46-5ubuntu4 on a fresh install of Ubuntu 9.10:
file.svg:493: parser error : PCDATA invalid Char value 1 id="tspan2654"></tspan></text> ^
file.svg:635: parser error : PCDATA invalid Char value 1 id="tspan2736"></tspan></text> ^
file.svg:971: parser error : PCDATA invalid Char value 1 id="tspan2934"></tspan></text> ^
This behavior seems to be somewhat unpredictable, since if I recall correctly I have sometimes generated SVGs from the same PDF with the same version of the software that don't suffer from it. Of course, going through and stripping the illegal characters is a [tedious] workaround.
...
For what it's worth, here is a snippet of the SVG from a "malformed" file, where ^A represents the illegal character, suggesting this is just being passed through from the imported document in violation of some schema that's caught when reloading:
Don't have time this AM to try the test case, but I'm seeing a similar situation where a SVGZ saved in some unknown version of Inkscape (file metadata does say 0.46), using an imported PDF, contains character 0001s that the parser doesn't like with a fresh install of Inkscape 0.46-5ubuntu4 on a fresh install of Ubuntu 9.10:
file.svg:493: parser error : PCDATA invalid Char value 1
id="tspan2654 "></tspan> </text>
^
id="tspan2736 "></tspan> </text>
^
id="tspan2934 "></tspan> </text>
^
file.svg:635: parser error : PCDATA invalid Char value 1
file.svg:971: parser error : PCDATA invalid Char value 1
This behavior seems to be somewhat unpredictable, since if I recall correctly I have sometimes generated SVGs from the same PDF with the same version of the software that don't suffer from it. Of course, going through and stripping the illegal characters is a [tedious] workaround.
...
For what it's worth, here is a snippet of the SVG from a "malformed" file, where ^A represents the illegal character, suggesting this is just being passed through from the imported document in violation of some schema that's caught when reloading:
<text
transform= "matrix( 1,0,0,- 1,93.600528, 484.98) "
id="text2652" ><tspan
style= "font-size: 7.98000002px; font-variant: normal; font-weight: normal; fo normal; writing- mode:lr- tb;fill: #000000; fill-opacity: 1;fill- rule:nonze none;font- family: Wingdings; -inkscape- font-specificat ion:Wingdings- Regu
id="tspan2654 ">^A</tspan> </text>
nt-stretch:
ro;stroke:
lar"
x="0"
y="0"
Importing the same source PDF into 0.46-5ubuntu4 and saving SVG generates the following, stripping/ignoring the character, at least today:
<text
id="text2652"
transform= "matrix( 1,0,0,- 1,93.600528, 484.98) ">
id= "tspan2654"
style= "font-size: 7.98000002px; font-variant: normal; font-weight: normal; font-stretch: normal; writing- mode:lr- tb;fill: #000000; fill-opacity: 1;fill- rule:nonzero; stroke: none;font- family: Wingdings; -inkscape- font-specificat ion:Wingdings- Regular" ></tspan>
<tspan
y="0"
x="0"
</text>
I'll attach the source PDF in case anyone cares to examine its use/abuse of Wingdings/control characters in the first place.