Hello Thomas,
unfortunately, your suggestion did not work as intended.
If I add
result.setNodeValue(importedNode.getNodeValue());
return result;
> to the ATTRIBUTE_NODE case of the importNode method of
> batik.dom.AbstractDocument
the problem persists.
I suspect this is due to a lack of events fired - in the
"setNodeValue" method, an Event is only fired, when OwnerElement is not
'null'. This, however, is the case in both the dom4j.DOMWriter class
used to create the original batik.SVGDOMDocument as well as by the
DOMUtils when creating the clone.
I further believe that this is due to the order of calls in
AbstractElement$ExtendedNamedNodeHashmap:
Within the method setUnspecifiedAttribute, at first, the Attribute Value
is set via a call to AbstractAttr.setValue, and _afterwards_ the
OwnerElement is set indirectly by calling setItemNS (which calls
setOwnerElement, among other things).
Do you know whether the order of things can be reversed without negative
side effects (or if it's at least worth trying)?
If so, I think, the problem should be solved.
In high hopes
-Urs
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
