Hi Eric,

> First, if we use DOMUtilities to write out the Document from our
> canvas, we get a duplicate xmlns attribute in the resulting SVG file,
> causing every viewer I've tried to refuse to render it. This is only a
> minor inconvenience, but seems like a real bug. I've only observed the
> problem under Windows 7 64-bit, but I haven't checked under other
> operating systems yet. We're using the Batik 1.7 libraries.

Weird. When you mean duplicate, to which one are you referring, the
one for the SVG namespace? Please paste a short snippet containing the
duplicate attribute. Are you able to check if this still reproduces
using Batik 1.8pre? There are (slightly outdated) nightly builds [1],
handy when no build environment is available.


> Second, and much more severe for our purposes: JSVGCanvas seems to
> differ from our intentions (and both Firefox and Chrome) in rendering
> multiple <tspan>'s inside a <text> element with the
> text-anchor="middle" property. When we use either our own Canvas or
> Squiggle, all but the last <tspan> render their content as if they had
> text-anchor="start" - the last one renders 'correctly', with text
> anchored at its middle.

I confirm that it appears to be buggy behavior and have reported bug
XXXX [2]. Playing with the issue I found a workaround: you seem to
have trailing space in all but the last <tspan> elements (within the
several available <text> elements). If you trim that whitespace, the
issue no longer reproduces. ;-)

Note that Firebug also has a related bug [3] while dealing with
text-anchor="end" which may also become handy if you are making
further experiments with this. :-)


> This behavior repeats on both Windows XP
> 32-bit and Windows 7 64-bit. Strangely enough, this gets different
> behavior on Linux... On Linux (Ubuntu 10.04, to be specific), all
> <tspan>'s in such a situation render correctly.

Again, weird. I've marked the bug as Windows-only, and I'm holding
that someone can confirm this for MacOS as well.


> Here's a sample SVG file where you can see the difference in
> rendering. The only edit I've made to it is to remove the duplicate
> xmlns attribute, so it can render successfully.

I'm attaching the modified test case which no longer reproduces the
issue. The only modification I made was replacing " </tspan>" with
"</tspan>" (which effectively trims all the trailing spaces found in
<tspan> elements).


> Thanks,
> - Eric Astor

Hope this helps,
 Helder


[1] http://mcc.id.au/batik-nightly/
[2] https://issues.apache.org/bugzilla/show_bug.cgi?id=49736
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=503075

<<attachment: lastCharmTree-TrailingWhitespaceTrimmed.svg>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to