Hi Jeremias
I'm running 1.5.0_06 (linux) so it's strange the the problem doesn't
occur for you with 1.5.0_03. Also seems a bit odd that there would be
differences between linux and windows (assuming you're using windows)
xml parser/xslt versions.
Anyway, I copied the jars into endorsed as specified, and indeed that
does fix the problem. Good news!
Thanks for the prompt reply and your efforts.
Kind regards
Jason
Jeremias Maerki wrote:
Horrible! Here's what I found out:
It's Sun's fault. :-) Mostly, anyway.
I've recently changed FOP to use the JAXP/TRaX API (javax.transform) to
build (SVG) DOMs from a SAX stream. If Xalan-J is the primary XSLT
implementation, org.apache.xml.utils.DOMBuilder is used internally to
build the DOM. So much for the context.
The symptom: The BridgeException happens because Batik cannot find the
"r" attribute. Batik cannot find the "r" attribute because
org.apache.batik.dom.AbstractElement.get(String, String) encounters a
mismatch: The "r" attribute has been specified with an empty String ("")
as the namespace URI but is now looking for "r" with a null namespace
URI. This means that the attribute was set on the DOM element using an
empty String in the namespace URI by DOMBuilder.
If you let the SAXSVGDocumentFactory (a Batik class) do the same job, an
empty String reported by a SAX parser will be converted to a null value.
No error happens. So, for SVG, this would be a work-around we could
implement.
Even the latest Sun JDK 1.4.2_10 contains an ancient version of Apache
Xalan-J as its XSLT implementation. With bugs, of course. Xalan-J
versions (Apache versions that is) after 2000-12-31 have a change that
convert the namespace URI from a null namespace URI to an empty String
[1]. (This tells something about how old the code in Sun JDK 1.4.2_10 is).
Note, this is actually the opposite of what we would expect, since the
DOM Level 2 specification says that null represents the right value for
an attribute that is in no namespace. However, the SAX AttributesImpl [2]
expects an empty String to indicate the same. It's interesting thing is
a change [3] on 2002-07-10 which suddenly starts to convert empty
Strings to null values (which is actually my expectation).
I see several ways to go:
- The easiest (and my recommendation) is to use the endorsed standards
override mechanism to replace the XML parser and XSLT implementation.
- Change SVG building to use SAXSVGDocumentFactory. Downside: this only
helps with SVG and not with any other namespace.
- Look into the Batik source code if a defensive check could be added so
empty Strings are converted to null values. Downside: Is available only
after the next Batik release and it may not be the right thing to do.
But I can still let them know about the issue.
- Create our own DOMBuilder. Downside: Code duplication, a lot of work,
potential bugs etc.
Woa, a lot of text. My opinion: Mark this as "WON'T FIX" and rely on
replacing the buggy Xalan implementation as described earlier.
[1] http://svn.apache.org/viewcvs.cgi?rev=334122&view=rev
[2]
http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/core.html#ID-745549614
(see setAttributeNS)
[3] http://svn.apache.org/viewcvs.cgi?rev=336570&view=rev
On 24.02.2006 10:02:24 Jeremias Maerki wrote:
Jason, after some tests I found out that this only fails with JDK 1.4.2
without any overridden endorsed libraries [1] in place. It doesn't
happen with an unpatched JDK 1.5.0_03, for example. I always use the
latest Xerces and Xalan version which is why I didn't stumble upon the
problem when I changed the way SVG is parsed in FOP Trunk recently. I'll
try to track down the problem because this is still a little suspicious.
But since the XML parser and XSLT implementation shipped with JDK 1.4
are known to have issues I suggest you replace those in your JDK
installation. Despite the problem at hand it is (IMO) generally a good
idea to do.
To replace the JARs:
Create a directory called "endorsed" under the jre/lib directory of your
JDK installation (applies to all versions >= 1.4.0) and put all the
XML-related JARs shipped with FOP in there, i.e. "xml-apis", "xercesImpl",
"xalan" and "serializer".
[1] http://java.sun.com/j2se/1.4.2/docs/guide/standards/
On 23.02.2006 09:17:23 Jason R Briggs wrote:
Anyone else experiencing problems with SVG with the trunk version of fop?
For example, the FO below works perfectly in 0.91beta, but doesn't
throws an error (see below FO) in the latest trunk version.
Unfortunately I can't use 0.91 because I have some really odd layout
problems that completely vanish in trunk.
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
