You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-users@xmlgraphics.apache.org by Jason R Briggs <ja...@rhe.co.nz> on 2006/02/23 09:17:23 UTC
fop trunk svg problems
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.
<?xml version="1.0" encoding="utf-8"?>
<fo:root xmlns:fo="http://www.w3.org/1999/XSL/Format"
xmlns:svg="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink">
<fo:layout-master-set>
<fo:simple-page-master master-name="A4"
page-height="29.7cm"
page-width="21cm"
margin-top="15mm"
margin-bottom="15mm"
margin-left="15mm"
margin-right="15mm">
<fo:region-body margin-top="0cm"/>
<fo:region-after />
</fo:simple-page-master>
</fo:layout-master-set>
<fo:page-sequence master-reference="A4">
<fo:flow flow-name="xsl-region-body">
<fo:block>
<fo:instream-foreign-object text-align="center">
<svg:svg width="3mm" height="3mm" viewBox="0 0 50 50">
<svg:circle cx="25" cy="25" r="24" fill="none"
stroke="black" stroke-width="2" />
</svg:svg>
</fo:instream-foreign-object>
</fo:block>
</fo:flow>
</fo:page-sequence>
</fo:root>
Throws the following exception:
[java] (pdf.PDFSVGHandler 183 ) svg graphic could
not be built: file:/home/jason/classes/:-1
[java] The attribute "r" of the element <circle> is required
[java] org.apache.batik.bridge.BridgeException:
file:/home/jason/rhe/e-asTTle/trunk/scratchpad/jason/classes/:-1
[java] The attribute "r" of the element <circle> is required
[java] at
org.apache.batik.bridge.SVGCircleElementBridge.buildShape(Unknown Source)
[java] at
org.apache.batik.bridge.SVGShapeElementBridge.createGraphicsNode(Unknown
Source)
[java] at
org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(Unknown Source)
[java] at
org.apache.batik.bridge.GVTBuilder.buildComposite(Unknown Source)
[java] at org.apache.batik.bridge.GVTBuilder.build(Unknown Source)
[java] at
org.apache.fop.render.pdf.PDFSVGHandler.renderSVGDocument(PDFSVGHandler.java:181)
[java] at
org.apache.fop.render.pdf.PDFSVGHandler.handleXML(PDFSVGHandler.java:80)
[java] at
org.apache.fop.render.AbstractRenderer.renderXML(AbstractRenderer.java:842)
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: fop trunk svg problems
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Jason,
it seems I forgot to disable the "endorsed" directory in my 1.5.0_03 JDK
when I did the test. Sloppy me. Sorry. The problem does occur with
an unpatched 1.5.0_03. All the worse for Sun. :-)
On 24.02.2006 22:07:14 Jason R Briggs wrote:
> 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: fop-users-unsubscribe@xmlgraphics.apache.org
> > For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: fop trunk svg problems
Posted by Jason R Briggs <ja...@rhe.co.nz>.
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: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: fop trunk svg problems
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 24.02.2006 12:22:43 b.ohnsorg wrote:
>
> ----- original Nachricht --------
>
> Betreff: Re: fop trunk svg problems
> Gesendet: Fr 24 Feb 2006 11:56:59 CET
> Von: "Jeremias Maerki"<de...@jeremias-maerki.ch>
>
> > Horrible! Here's what I found out:
> >
> > It's Sun's fault. :-) Mostly, anyway.
>...so why is mine working? (The only difference is that I use
> blackdown-java, maybe the use a better xalan version. At the office I
> only use the endorsed mechanism due to the fact, that we're only
> allowed to use Xalan as XSLT-proc. Additionally I have a preceeding
> DocBook->FO-step which uses a separate Xalan lib...and so on)
Well, you've replaced Xalan and that's why it works. Blackdown currently
uses the source code from Sun's 1.4.2_10 so if you removed your special
Xalan version you'd experience the same problem.
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: fop trunk svg problems
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
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: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: fop trunk svg problems
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
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: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org