On Jan 14, 2008, at 19:04, Andreas L Delmelle wrote:

On Jan 14, 2008, at 14:23, Max Berger wrote:
<snip />
- If it is not, where do i need to start looking for the bug? Jeuclid
completely ignores namespaces in attributes, so it is either in the
fop/plugin interface, fop itself, or the xerces parser?

I can't quite put my finger on it yet, but if I were to start looking, I'd try placing a breakpoint in the private org.apache.fop.fo.XMLObj#setAttributes(). See what happens there. Judging from the code, the attributes without a prefix are added to the node via the generic org.w3c.dom.Element#setAttribute().

Maybe problems with the (writable) DOM implementation? Or does the MathML extension not use the 'XMLObj.element' member, or ....?

Just had a closer look at org.apache.fop.mathml.MathMLElement... and I can almost see what's happening.

Attempt at reconstruction:

-> XMLObj.processNode() : the SAX Attributes are assigned to XMLObj.attr
-> XMLObj.createBasicDocument()
  -> XMLObj.buildTopLevel() : XMLObj.element instantiated
-> XMLObj.setAttributes() : all attributes in the default namespace are associated with XMLObj.element via setAttributes(), the others via setAttributeNS()

If the node itself does not have an 'xmlns' attribute, the namespace is forced to MathMLElement.getNamespaceURI().

At this point, the namespace is still MathML.
Hint: look at the implementation... this one switches namespace at some point.

To make a long story short, further on in the process, InstreamForeignObjectLM calls MathMLElement.getDOMDocument(). That's where the namespace switches, because the element is converted to SVG. The call to getNamespaceURI() will return the SVG namespace, but the original MathML attributes are still in the MathML namespace, and that is (most likely) to be the reason they are disregarded.

Not really an idea on how to fix it, though. :/



Reply via email to