FYI, I had to post-process the cloned DOM by transfering the document URI myself. Looking at AbstractDocument.copyInto() which isn't called when using DOMUtilities.deepCloneDocument(), there might actually be other values that may need to be copied. But the document URI was the important one.
http://svn.apache.org/viewvc?rev=724310&view=rev On 07.12.2008 19:06:16 Jeremias Maerki wrote: > Thanks for the hint. That made things easier. I've committed the > necessary changes but without the potential performance optimizations we > discussed. > > On 07.12.2008 17:02:34 thomas.deweese wrote: > > Hi Jeremias, > > > > Jeremias Maerki <[EMAIL PROTECTED]> wrote on 12/07/2008 09:04:57 AM: > > > > > Ok, I've created a Bugzilla issue to track this issue in FOP: > > > https://issues.apache.org/bugzilla/show_bug.cgi?id=46360 > > > > Ok, Thanks. > > > > > A short test shows that I can't easily clone the document if it has a > > > document type. The following is a patch the would fix the exception. > > [...] > > > And I don't even know if the patch here is even plausible. > > > > I strongly suspect that it's intentional that the document will not > > create a DocumentType Node as this should be provided when the > > document is created. > > > > > But I guess I'll need to work around that outside of Batik as we'd have > > > to wait for a Batik release before we can release a new FOP with the fix > > > applied. So I'm planning to do this: > > > > I suggest using: > > batik.dom.util.DOMUtilities.deepCloneDocument > > (Document doc, DOMImplementation impl); > > > > This has been in Batik for quite a while and has code to > > work around this exact problem. <snip/> Jeremias Maerki --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
