Hi Urs,
Urs Reupke wrote:
I'm guessing this is the problem. I think that we aren't tracking
the addition/removal of child nodes directly from the Attribute Node.
I'm looking into this now, the tricky bit is that it isn't clear to
me what events should be sent in this case (DOM Node Inserted, DOM Attr
Modified? both?).
This is a Batik internal problem, not dependent on the creator of the
SVG Document (dom4j in my case) or the SVG Specification, isn't it?
Yes, I would consider this a Batik problem no dom4J. It is caused
by dom4J building the document in an "odd" way but I think they are
within the letter of the spec.
Also, am I correct in assuming that firing both wouldn't hurt anything
but speed?
Yes, I think so.
In the interest of continuing our project, if you could give me some
further pointers, I could try to find out what to do. I cannot promise
anything, however, since my knowledge of the Batik code base is close to 0.
I suspect that the 'quickest' thing to do would be to deep clone the
dom4j generated SVG Document into another SVG Document (this should fix
the attribute weirdness). You could also try some simple fixes for
the problem, probably involving implementing 'nodeAdded' in
batik.dom.AbstractAttr to fire a dom attr modified event
(take a look at setNodeValue for an example of how to do this).
Yes, the Document maintains a hash table of all the Id's on any
element it created. This is what getElementById uses so that this
is a quick operation.
Alright, thank you. I've had another look - guess the table is clearly
labled. I noticed that all three of the "xBYy" hash tables -
ElementsByID, ElementsByTagnames, ElementsByTagnamesNS - are 'null',
so the problem might extend further than just IDs.
I think they are null because it thinks the id attributes are
'empty' so there is nothing to store.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
