Hello,
My posted workaround works fine for me. Anyway i tested it with my "old" code..
SVGDocument doc = (SVGDocument) svgDoc.cloneNode(true);
Bevor i removed the DocumentType ... Then it works don't mind if 1.0 or 1.1 is
set as version... With 1.2 i get an exception but not at the cloning...
But when i'am using the Patch from the bug 46791 and leave the document
unchanged (only the Documenttype is in it and version is 1.0 =>default) the
exception
org.w3c.dom.DOMException: Cannot import node.
at
org.apache.batik.dom.AbstractNode.createDOMException(AbstractNode.java:408)
at
org.apache.batik.dom.AbstractDocument.importNode(AbstractDocument.java:401)
at
org.apache.batik.dom.AbstractDocument.importNode(AbstractDocument.java:326)
at
org.apache.batik.dom.AbstractDocument.cloneNode(AbstractDocument.java:435)
at at.pke.ag.print.Printer.createDocument(Printer.java:559)
Occures !
I mean i copied the changes from 46791 into the class
org.apache.batik.bridge.svg12.SVG12TextElementBridge !?
For me the best and easied way is to use the workaround i posted, because i'am
not able to remove the documenttype because the svg files are generated from
Mirosoft Vision with a product from a nother company... I don't know if the can
make changes easily ?!
But if there a tests i can to to fix the "real" problem tell me.
Mit freundlichen Grüßen Michael
-----Ursprüngliche Nachricht-----
Von: Helder Magalhães [mailto:[email protected]]
Gesendet: Mittwoch, 19. August 2009 11:12
An: [email protected]
Betreff: Re: Problem with clone document.. 1.7 okay => 1.8pre not
Hi Michael,
> Version is 1.8 from SVN so from today (so after 6.AUG.2009) ?! I saw that 10
> is DOCUMENT_TYPE_NODE...
> The types are defined in the Node class. I didn't check if something changed
> since 1.7 ...
Have you tried applying (locally) the patch from bug 46791 [1]? It's tightly
related and, although I haven't tested for sure, might help:
it states that if an "element has got a child element in a custom namespace",
which happens in your test cases ("xmlns:v" and "xmlns:ag"). If it does help
working around this potential issue, please make sure to follow up in this
thread and/or in the correspondent bug report [1]. ;-)
You can also try a quick test:
1. Take a test case where this is occurring:
2. Remove the doc[ument] type declaration; 3. Set the version to in the root
SVG document to "1.1".
That should force the 1.1 document "mode", therefore possibly working around
the behavior (stated in bug 46791). Note that, even if this works, I'd still
ask you to try applying the patch afterward and checking in an unmodified test
case (the proper way of solving this).
> There is no version of SVG defined in the document i am using ? Where can i
> see which svg version the file is ??
Well, usually this can be forced by using the "version" attribute [2] in the
root "svg" element. The doc[ument] type declaration can also currently be
forcing it (to "1.0", in your test cases). I'm not sure about what is the
precedence order and/or what is assumed when no version information is
specified (but I'm convinced the specification addresses that).
> It happens with every svg i am using (... This are only a very small
> one ...)
Thanks for the sample test cases. Feedback is usually much better with more
useful data available. ;-)
Regards,
Helder
[1] https://issues.apache.org/bugzilla/show_bug.cgi?id=46791
[2] http://www.w3.org/TR/SVG/struct.html#SVGElementVersionAttribute
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
