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:
MathMLElement.processNode()
-> 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. :/
Cheers
Andreas