You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-users@xmlgraphics.apache.org by Brian Lynn <br...@gemsoup.com> on 2003/05/12 23:27:35 UTC
URI resolution issues in Batik with FOP
I'm trying to use FOP to generate a PDF document from a .fo source that
has a number of SVGs. Some of the SVGs render properly, others fail with
an IO error. The problem in the ones that fail appears to be to do
with resolving intra-document references in a "clip-path" attribute of a
<rect> element.
Here is an example of a reference:
<rect x="117" y="11" width="30" height="26" class="elTypeBkgnd"
rx="5" ry="5" clip-path="url(#t:EquityValuation/a:id)"/
The referenced element is present in the SVG file:
<clipPath id="t:EquityValuation/a:id">
<rect x="116" y="25" width="32" height="12"/>
</clipPath>
But when I run it, I get an exception something like:
[ERROR] svg graphic could not be built:
file:/C:/fpml401/html/svg/fpml-eqd-4-0_xsd/comp00038.svg:-1
An I/O error occured while processing the URI '#t:EquityValuation/a:id'
specified on the element <rect>
org.apache.batik.bridge.BridgeException:
file:/C:/fpml401/html/svg/fpml-eqd-4-0_xsd/comp00038.svg:-1
An I/O error occured while processing the URI '#t:EquityValuation/a:id'
specified on the element <rect>
at
org.apache.batik.bridge.BridgeContext.getReferencedElement(BridgeContext
.java:457)
at
org.apache.batik.bridge.CSSUtilities.convertClipPath(CSSUtilities.java:6
60)
at
org.apache.batik.bridge.AbstractGraphicsNodeBridge.buildGraphicsNode(Abs
tractGraphicsNodeBridge.java:124)
I've found that I can work around the problem by running Batik as a
standalone program (using batik-rasterizer.jar) and changing the url in
the SVG document to include the filename of the document itself, eg.
clip-path="url(./comp00038.svg#t:EquityValueation/a:id)"
However, running Batik standalone causes other problems, and the
workaround doesn't work when running Batik under FOP.
I think that there is a problem in the URIResolver class or in something
that it calls. Maybe it's confused by something in my SVG file (which is
generated by XML Authority.) I've attached a copy of the SVG file, and
here is the root element:
<?xml version="1.0" encoding="utf-8"?>
<svg xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink"
width="291pt"
height="186pt"
viewBox="0 0 291 186"
zoomAndPan="magnify"
version="1.0"
preserveAspectRatio="xMidYMid meet"
contentScriptType="text/ecmascript"
contentStyleType="text/css">
There are some css styles in the SVG, but there is no css file that is
referenced.
Has anyone seen anything similar? Does anyone know of a solution or a
workaround to this problem? I'm not currently equipped to debug
FOP/Batik, but looking at the code suggests that there may be a problem
in trying to read the CSS parent element in the getCascadedXMLBase
method of the XMLBaseSupport class, which is called by URI resolver. Or
maybe it's something else.
Thanks in advance for any help,
Brian Lynn
Founder and CTO
Gem Soup LLC - The FpML Community
http://gemsoup.com
845-687-7289 (direct)
845-532-7849 (cell)
Re: SVG or Flash & Batik vs. Linux Tomcat server
Posted by Jan Vesely <ja...@quinity.com>.
Thank you all for your help!
Jan
----- Original Message -----
From: "Thomas E Deweese" <th...@kodak.com>
To: "Batik Users" <ba...@xml.apache.org>
Cc: "Jan Vesely" <ja...@quinity.com>
Sent: Thursday, May 15, 2003 1:56 PM
Subject: Re: SVG or Flash & Batik vs. Linux Tomcat server
> >>>>> "SW" == Stefan werner <st...@netcologne.de> writes:
>
> SW> "Jan Vesely" wrote: To: "Batik Users"
> SW> <ba...@xml.apache.org> Sent: Tuesday, May 13, 2003 10:32 AM
>
> SW> Hello Jan,
>
> >> Hallo everyone,
> >>
> >> I have a question. I want to make a new front end to an internet
> >> application with a J2EE back end. All the database accessing is
> >> done in the Java part. I want to use the new front end only for
> >> (interactive) visualisation of my data (menu's, scalable/zoomable
> >> images, clickable links). I might even want to insert some
> >> animations. I do not plan to edit the data in this "pretty view".
> >>
> >> And the question is - what is a better choice in my situation: SVG
> >> (either with or without Batik), Flash, or something else?
>
> SW> At http://groups.yahoo.com/group/svg-developers you find several
> SW> threads about this question.
>
> Good pointer, my intial reaction is that SVG would be best (simply
> because it is generally easier to generate from a back end and Flash's
> binary format), but I'm probably biased :)
>
> >> And another, smaller question is - I have been playing with
> >> generating SVG with Batik from a Java Servlet. When I installed
> >> this small experimental application on a Windows Tomcat server, all
> >> worked well. But when I did the same on a Linux Tomcat (same
> >> version), it did not work (only the SVG part, the rest worked fine)
> >> ... any idea why?
>
> SW> May be you do not have X-Server running on your Linux-box?
>
> Good catch, I should point out that with JDK 1.4 you can run in
> "headless mode" on UNIX. Earlier versions of Batik had some issues
> with this but they should all be resolved at this point.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-users-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: SVG or Flash & Batik vs. Linux Tomcat server
Posted by Thomas E Deweese <th...@kodak.com>.
>>>>> "SW" == Stefan werner <st...@netcologne.de> writes:
SW> "Jan Vesely" wrote: To: "Batik Users"
SW> <ba...@xml.apache.org> Sent: Tuesday, May 13, 2003 10:32 AM
SW> Hello Jan,
>> Hallo everyone,
>>
>> I have a question. I want to make a new front end to an internet
>> application with a J2EE back end. All the database accessing is
>> done in the Java part. I want to use the new front end only for
>> (interactive) visualisation of my data (menu's, scalable/zoomable
>> images, clickable links). I might even want to insert some
>> animations. I do not plan to edit the data in this "pretty view".
>>
>> And the question is - what is a better choice in my situation: SVG
>> (either with or without Batik), Flash, or something else?
SW> At http://groups.yahoo.com/group/svg-developers you find several
SW> threads about this question.
Good pointer, my intial reaction is that SVG would be best (simply
because it is generally easier to generate from a back end and Flash's
binary format), but I'm probably biased :)
>> And another, smaller question is - I have been playing with
>> generating SVG with Batik from a Java Servlet. When I installed
>> this small experimental application on a Windows Tomcat server, all
>> worked well. But when I did the same on a Linux Tomcat (same
>> version), it did not work (only the SVG part, the rest worked fine)
>> ... any idea why?
SW> May be you do not have X-Server running on your Linux-box?
Good catch, I should point out that with JDK 1.4 you can run in
"headless mode" on UNIX. Earlier versions of Batik had some issues
with this but they should all be resolved at this point.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: SVG or Flash & Batik vs. Linux Tomcat server
Posted by Stefan werner <st...@netcologne.de>.
"Jan Vesely" wrote:
To: "Batik Users" <ba...@xml.apache.org>
Sent: Tuesday, May 13, 2003 10:32 AM
Hello Jan,
> Hallo everyone,
>
> I have a question. I want to make a new front end to an internet
application
> with a J2EE back end. All the database accessing is done in the Java part.
I
> want to use the new front end only for (interactive) visualisation of my
> data (menu's, scalable/zoomable images, clickable links). I might even
want
> to insert some animations. I do not plan to edit the data in this "pretty
> view".
>
> And the question is - what is a better choice in my situation: SVG (either
> with or without Batik), Flash, or something else?
At http://groups.yahoo.com/group/svg-developers you find several threads
about this question.
> And another, smaller question is - I have been playing with generating SVG
> with Batik from a Java Servlet. When I installed this small experimental
> application on a Windows Tomcat server, all worked well. But when I did
the
> same on a Linux Tomcat (same version), it did not work (only the SVG part,
> the rest worked fine) ... any idea why?
May be you do not have X-Server running on your Linux-box?
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
SVG or Flash & Batik vs. Linux Tomcat server
Posted by Jan Vesely <ja...@quinity.com>.
Hallo everyone,
I have a question. I want to make a new front end to an internet application
with a J2EE back end. All the database accessing is done in the Java part. I
want to use the new front end only for (interactive) visualisation of my
data (menu's, scalable/zoomable images, clickable links). I might even want
to insert some animations. I do not plan to edit the data in this "pretty
view".
And the question is - what is a better choice in my situation: SVG (either
with or without Batik), Flash, or something else?
And another, smaller question is - I have been playing with generating SVG
with Batik from a Java Servlet. When I installed this small experimental
application on a Windows Tomcat server, all worked well. But when I did the
same on a Linux Tomcat (same version), it did not work (only the SVG part,
the rest worked fine) ... any idea why?
Thanks!
Jan
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
RE: URI resolution issues in Batik with FOP
Posted by Brian Lynn <br...@gemsoup.com>.
Thanks, Vincent, that makes it clearer what's going on.
Brian Lynn
Founder and CTO
Gem Soup LLC - The FpML Community
http://gemsoup.com
845-687-7289 (direct)
845-532-7849 (cell)
-----Original Message-----
From: Vincent Hardy [mailto:vincent.hardy@sun.com]
Sent: Tuesday, May 13, 2003 3:18 AM
To: Batik Users
Cc: brian.lynn@gemsoup.com
Subject: Re: URI resolution issues in Batik with FOP
Hi Brian,
The short answer is that the document you are using has ":" in ids, and
Batik had a bug with such ids. Thomas recently fixed that issue, so you
should get things working if you switch to the CVS version of Batik.
Regarding you suggested fix, I have included details below.
Vincent.
SVG uses XML Base which means that all relative URIs are relative to the
value of the xml:base URI. By default, the xml:base value is inherited
and will default to the value of the current document's URI.
Thomas and I had a discussion about this recently and we concluded that
the rule for fragments is the same as for relative URIs. Thomas sent a
reference to the RFC that backs up his arguments.
Here is an exerpt of the email Thomas sent on a discussion we had around
that topic recently:
> 4.2. Same-document References
>
> A URI reference that does not contain a URI is a reference to the
> current document. In other words, an empty URI reference within a
> document is interpreted as a reference to the start of that
document,
> and a reference containing only a fragment identifier is a
reference
> to the identified fragment of that document. Traversal of such a
> reference should not result in an additional retrieval action.
> However, if the URI reference occurs in a context that is always
> intended to result in a new request, as in the case of HTML's FORM
> element, then an empty URI reference represents the base URI of the
> current document and should be replaced by that URI when
transformed
> into a request.
>
> This combined with the fact that xml:base is defined to replace the
> base URI of the current document makes me almost 100% certain that we
> are doing the correct thing (also it is truly what makes sense to
> me).
>
> I'm not really hung up on this, but I think it would be a mistake
> to have one of these fail and the other succeed (because '#abc' is
> only in 'foo.svg' not the current document):
>
> <g xml:base="foo.svg">
> <use xlink:href="#abc">
> <use xlink:href="foo.svg#abc">
> </g>
>
>
I agree with Thomas' analysis.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: URI resolution issues in Batik with FOP
Posted by Vincent Hardy <vi...@sun.com>.
Hi Brian,
The short answer is that the document you are using has ":" in ids, and
Batik had a bug with such ids. Thomas recently fixed that issue, so you
should get things working if you switch to the CVS version of Batik.
Regarding you suggested fix, I have included details below.
Vincent.
SVG uses XML Base which means that all relative URIs are relative to the
value of the xml:base URI. By default, the xml:base value is inherited
and will default to the value of the current document's URI.
Thomas and I had a discussion about this recently and we concluded that
the rule for fragments is the same as for relative URIs. Thomas sent a
reference to the RFC that backs up his arguments.
Here is an exerpt of the email Thomas sent on a discussion we had around
that topic recently:
> 4.2. Same-document References
>
> A URI reference that does not contain a URI is a reference to the
> current document. In other words, an empty URI reference within a
> document is interpreted as a reference to the start of that document,
> and a reference containing only a fragment identifier is a reference
> to the identified fragment of that document. Traversal of such a
> reference should not result in an additional retrieval action.
> However, if the URI reference occurs in a context that is always
> intended to result in a new request, as in the case of HTML's FORM
> element, then an empty URI reference represents the base URI of the
> current document and should be replaced by that URI when transformed
> into a request.
>
> This combined with the fact that xml:base is defined to replace the
> base URI of the current document makes me almost 100% certain that we
> are doing the correct thing (also it is truly what makes sense to
> me).
>
> I'm not really hung up on this, but I think it would be a mistake
> to have one of these fail and the other succeed (because '#abc' is
> only in 'foo.svg' not the current document):
>
> <g xml:base="foo.svg">
> <use xlink:href="#abc">
> <use xlink:href="foo.svg#abc">
> </g>
>
>
I agree with Thomas' analysis.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
RE: URI resolution issues in Batik with FOP
Posted by Brian Lynn <br...@gemsoup.com>.
I traced the URIResolver code and decided that a problem (not
necessarily the only problem) was that if the URI started with #, it
tried to load the document anyway when it shouldn't (since in this case
the URI is pointing to the current document). This caused the
DocumentLoader to blow up (for not fully understood reasons, maybe it
didn't like the #id.). To fix this I hacked the line that checks
whether the URI starts with #, to eliminate the additional check whether
the baseURI is null (see below). This fixed my problem, but I don't
understand what the baseURI test does, so it's a bit scary....
public Node getNode(String uri, Element ref)
throws MalformedURLException, IOException, SecurityException {
String baseURI = XMLBaseSupport.getCascadedXMLBase(ref);
//if ((baseURI == null) &&
//(uri.startsWith("#")))
if (uri.startsWith("#")) // Patch BAL to fix bug rendering
SVGs
return document.getElementById(uri.substring(1));
Can anyone explain what this check for baseURI==null is supposed to do
and why it's there?
In any event, it appears to me that some of the code here might be a tad
fragile ...
Cheers,
Brian Lynn
Founder and CTO
Gem Soup LLC - The FpML Community
http://gemsoup.com
845-687-7289 (direct)
845-532-7849 (cell)
-----Original Message-----
From: Brian Lynn [mailto:brian.lynn@gemsoup.com]
Sent: Monday, May 12, 2003 6:22 PM
To: 'Batik Users'
Subject: RE: URI resolution issues in Batik with FOP
G. Wade -
Thanks for the quick response. Looks like something dodgy ... but I
tried changing the '/' to underscore ('_') and no dice, same problem
(except that the message changed to reflect the different ID.)
I'm also wondering it it's possible that somehow there's a problem with
initializing the "documentLoader" object. But like I say I'm not set up
to debug yet.
FYI, these diagrams render OK in Internet Explorer 6.0. The problem
with Batik/FOP seems to be in the URI resolution due to some kind of
document context or other initialization issue.
Should have mentioned originally that I'm using Batik 1.5beta4b with FOP
0.20.5rc2, earlier versions have the same problem.
Brian Lynn
Founder and CTO
Gem Soup LLC - The FpML Community
http://gemsoup.com
845-687-7289 (direct)
845-532-7849 (cell)
-----Original Message-----
From: G. Wade Johnson [mailto:wade.johnson@abbnm.com]
Sent: Monday, May 12, 2003 5:50 PM
To: Batik Users
Subject: Re: URI resolution issues in Batik with FOP
I'm pretty certain that id fields are not allowed to contain the '/'
character. The XML 1.0 spec states that an ID fields must only contain
letters, digits, '.', '-', '_', ':', combining characters, and
extenders.
G. Wade
Brian Lynn wrote:
>
> I'm trying to use FOP to generate a PDF document from a .fo source
that
> has a number of SVGs. Some of the SVGs render properly, others fail
with
> an IO error. The problem in the ones that fail appears to be to do
> with resolving intra-document references in a "clip-path" attribute of
a
> <rect> element.
>
> Here is an example of a reference:
>
> <rect x="117" y="11" width="30" height="26"
class="elTypeBkgnd"
> rx="5" ry="5" clip-path="url(#t:EquityValuation/a:id)"/
>
> The referenced element is present in the SVG file:
> <clipPath id="t:EquityValuation/a:id">
> <rect x="116" y="25" width="32" height="12"/>
> </clipPath>
>
> But when I run it, I get an exception something like:
>
> [ERROR] svg graphic could not be built:
> file:/C:/fpml401/html/svg/fpml-eqd-4-0_xsd/comp00038.svg:-1
> An I/O error occured while processing the URI
'#t:EquityValuation/a:id'
> specified on the element <rect>
>
> org.apache.batik.bridge.BridgeException:
> file:/C:/fpml401/html/svg/fpml-eqd-4-0_xsd/comp00038.svg:-1
> An I/O error occured while processing the URI
'#t:EquityValuation/a:id'
> specified on the element <rect>
>
> at
>
org.apache.batik.bridge.BridgeContext.getReferencedElement(BridgeContext
> .java:457)
>
> at
>
org.apache.batik.bridge.CSSUtilities.convertClipPath(CSSUtilities.java:6
> 60)
>
> at
>
org.apache.batik.bridge.AbstractGraphicsNodeBridge.buildGraphicsNode(Abs
> tractGraphicsNodeBridge.java:124)
>
> I've found that I can work around the problem by running Batik as a
> standalone program (using batik-rasterizer.jar) and changing the url
in
> the SVG document to include the filename of the document itself, eg.
> clip-path="url(./comp00038.svg#t:EquityValueation/a:id)"
> However, running Batik standalone causes other problems, and the
> workaround doesn't work when running Batik under FOP.
>
> I think that there is a problem in the URIResolver class or in
something
> that it calls. Maybe it's confused by something in my SVG file (which
is
> generated by XML Authority.) I've attached a copy of the SVG file,
and
> here is the root element:
> <?xml version="1.0" encoding="utf-8"?>
> <svg xmlns="http://www.w3.org/2000/svg"
> xmlns:xlink="http://www.w3.org/1999/xlink"
> width="291pt"
> height="186pt"
> viewBox="0 0 291 186"
> zoomAndPan="magnify"
> version="1.0"
> preserveAspectRatio="xMidYMid meet"
> contentScriptType="text/ecmascript"
> contentStyleType="text/css">
>
> There are some css styles in the SVG, but there is no css file that is
> referenced.
>
> Has anyone seen anything similar? Does anyone know of a solution or a
> workaround to this problem? I'm not currently equipped to debug
> FOP/Batik, but looking at the code suggests that there may be a
problem
> in trying to read the CSS parent element in the getCascadedXMLBase
> method of the XMLBaseSupport class, which is called by URI resolver.
Or
> maybe it's something else.
>
> Thanks in advance for any help,
>
> Brian Lynn
>
> Founder and CTO
> Gem Soup LLC - The FpML Community
> http://gemsoup.com
> 845-687-7289 (direct)
> 845-532-7849 (cell)
>
>
>
------------------------------------------------------------------------
> Name: comp00038.svg
> comp00038.svg Type: Scalable Vector Graphics (image/svg+xml)
> Encoding: quoted-printable
>
>
------------------------------------------------------------------------
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-users-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
RE: URI resolution issues in Batik with FOP
Posted by Brian Lynn <br...@gemsoup.com>.
G. Wade -
Thanks for the quick response. Looks like something dodgy ... but I
tried changing the '/' to underscore ('_') and no dice, same problem
(except that the message changed to reflect the different ID.)
I'm also wondering it it's possible that somehow there's a problem with
initializing the "documentLoader" object. But like I say I'm not set up
to debug yet.
FYI, these diagrams render OK in Internet Explorer 6.0. The problem
with Batik/FOP seems to be in the URI resolution due to some kind of
document context or other initialization issue.
Should have mentioned originally that I'm using Batik 1.5beta4b with FOP
0.20.5rc2, earlier versions have the same problem.
Brian Lynn
Founder and CTO
Gem Soup LLC - The FpML Community
http://gemsoup.com
845-687-7289 (direct)
845-532-7849 (cell)
-----Original Message-----
From: G. Wade Johnson [mailto:wade.johnson@abbnm.com]
Sent: Monday, May 12, 2003 5:50 PM
To: Batik Users
Subject: Re: URI resolution issues in Batik with FOP
I'm pretty certain that id fields are not allowed to contain the '/'
character. The XML 1.0 spec states that an ID fields must only contain
letters, digits, '.', '-', '_', ':', combining characters, and
extenders.
G. Wade
Brian Lynn wrote:
>
> I'm trying to use FOP to generate a PDF document from a .fo source
that
> has a number of SVGs. Some of the SVGs render properly, others fail
with
> an IO error. The problem in the ones that fail appears to be to do
> with resolving intra-document references in a "clip-path" attribute of
a
> <rect> element.
>
> Here is an example of a reference:
>
> <rect x="117" y="11" width="30" height="26"
class="elTypeBkgnd"
> rx="5" ry="5" clip-path="url(#t:EquityValuation/a:id)"/
>
> The referenced element is present in the SVG file:
> <clipPath id="t:EquityValuation/a:id">
> <rect x="116" y="25" width="32" height="12"/>
> </clipPath>
>
> But when I run it, I get an exception something like:
>
> [ERROR] svg graphic could not be built:
> file:/C:/fpml401/html/svg/fpml-eqd-4-0_xsd/comp00038.svg:-1
> An I/O error occured while processing the URI
'#t:EquityValuation/a:id'
> specified on the element <rect>
>
> org.apache.batik.bridge.BridgeException:
> file:/C:/fpml401/html/svg/fpml-eqd-4-0_xsd/comp00038.svg:-1
> An I/O error occured while processing the URI
'#t:EquityValuation/a:id'
> specified on the element <rect>
>
> at
>
org.apache.batik.bridge.BridgeContext.getReferencedElement(BridgeContext
> .java:457)
>
> at
>
org.apache.batik.bridge.CSSUtilities.convertClipPath(CSSUtilities.java:6
> 60)
>
> at
>
org.apache.batik.bridge.AbstractGraphicsNodeBridge.buildGraphicsNode(Abs
> tractGraphicsNodeBridge.java:124)
>
> I've found that I can work around the problem by running Batik as a
> standalone program (using batik-rasterizer.jar) and changing the url
in
> the SVG document to include the filename of the document itself, eg.
> clip-path="url(./comp00038.svg#t:EquityValueation/a:id)"
> However, running Batik standalone causes other problems, and the
> workaround doesn't work when running Batik under FOP.
>
> I think that there is a problem in the URIResolver class or in
something
> that it calls. Maybe it's confused by something in my SVG file (which
is
> generated by XML Authority.) I've attached a copy of the SVG file,
and
> here is the root element:
> <?xml version="1.0" encoding="utf-8"?>
> <svg xmlns="http://www.w3.org/2000/svg"
> xmlns:xlink="http://www.w3.org/1999/xlink"
> width="291pt"
> height="186pt"
> viewBox="0 0 291 186"
> zoomAndPan="magnify"
> version="1.0"
> preserveAspectRatio="xMidYMid meet"
> contentScriptType="text/ecmascript"
> contentStyleType="text/css">
>
> There are some css styles in the SVG, but there is no css file that is
> referenced.
>
> Has anyone seen anything similar? Does anyone know of a solution or a
> workaround to this problem? I'm not currently equipped to debug
> FOP/Batik, but looking at the code suggests that there may be a
problem
> in trying to read the CSS parent element in the getCascadedXMLBase
> method of the XMLBaseSupport class, which is called by URI resolver.
Or
> maybe it's something else.
>
> Thanks in advance for any help,
>
> Brian Lynn
>
> Founder and CTO
> Gem Soup LLC - The FpML Community
> http://gemsoup.com
> 845-687-7289 (direct)
> 845-532-7849 (cell)
>
>
>
------------------------------------------------------------------------
> Name: comp00038.svg
> comp00038.svg Type: Scalable Vector Graphics (image/svg+xml)
> Encoding: quoted-printable
>
>
------------------------------------------------------------------------
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-users-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: URI resolution issues in Batik with FOP
Posted by "G. Wade Johnson" <wa...@abbnm.com>.
I'm pretty certain that id fields are not allowed to contain the '/'
character. The XML 1.0 spec states that an ID fields must only contain
letters, digits, '.', '-', '_', ':', combining characters, and
extenders.
G. Wade
Brian Lynn wrote:
>
> I'm trying to use FOP to generate a PDF document from a .fo source that
> has a number of SVGs. Some of the SVGs render properly, others fail with
> an IO error. The problem in the ones that fail appears to be to do
> with resolving intra-document references in a "clip-path" attribute of a
> <rect> element.
>
> Here is an example of a reference:
>
> <rect x="117" y="11" width="30" height="26" class="elTypeBkgnd"
> rx="5" ry="5" clip-path="url(#t:EquityValuation/a:id)"/
>
> The referenced element is present in the SVG file:
> <clipPath id="t:EquityValuation/a:id">
> <rect x="116" y="25" width="32" height="12"/>
> </clipPath>
>
> But when I run it, I get an exception something like:
>
> [ERROR] svg graphic could not be built:
> file:/C:/fpml401/html/svg/fpml-eqd-4-0_xsd/comp00038.svg:-1
> An I/O error occured while processing the URI '#t:EquityValuation/a:id'
> specified on the element <rect>
>
> org.apache.batik.bridge.BridgeException:
> file:/C:/fpml401/html/svg/fpml-eqd-4-0_xsd/comp00038.svg:-1
> An I/O error occured while processing the URI '#t:EquityValuation/a:id'
> specified on the element <rect>
>
> at
> org.apache.batik.bridge.BridgeContext.getReferencedElement(BridgeContext
> .java:457)
>
> at
> org.apache.batik.bridge.CSSUtilities.convertClipPath(CSSUtilities.java:6
> 60)
>
> at
> org.apache.batik.bridge.AbstractGraphicsNodeBridge.buildGraphicsNode(Abs
> tractGraphicsNodeBridge.java:124)
>
> I've found that I can work around the problem by running Batik as a
> standalone program (using batik-rasterizer.jar) and changing the url in
> the SVG document to include the filename of the document itself, eg.
> clip-path="url(./comp00038.svg#t:EquityValueation/a:id)"
> However, running Batik standalone causes other problems, and the
> workaround doesn't work when running Batik under FOP.
>
> I think that there is a problem in the URIResolver class or in something
> that it calls. Maybe it's confused by something in my SVG file (which is
> generated by XML Authority.) I've attached a copy of the SVG file, and
> here is the root element:
> <?xml version="1.0" encoding="utf-8"?>
> <svg xmlns="http://www.w3.org/2000/svg"
> xmlns:xlink="http://www.w3.org/1999/xlink"
> width="291pt"
> height="186pt"
> viewBox="0 0 291 186"
> zoomAndPan="magnify"
> version="1.0"
> preserveAspectRatio="xMidYMid meet"
> contentScriptType="text/ecmascript"
> contentStyleType="text/css">
>
> There are some css styles in the SVG, but there is no css file that is
> referenced.
>
> Has anyone seen anything similar? Does anyone know of a solution or a
> workaround to this problem? I'm not currently equipped to debug
> FOP/Batik, but looking at the code suggests that there may be a problem
> in trying to read the CSS parent element in the getCascadedXMLBase
> method of the XMLBaseSupport class, which is called by URI resolver. Or
> maybe it's something else.
>
> Thanks in advance for any help,
>
> Brian Lynn
>
> Founder and CTO
> Gem Soup LLC - The FpML Community
> http://gemsoup.com
> 845-687-7289 (direct)
> 845-532-7849 (cell)
>
>
> ------------------------------------------------------------------------
> Name: comp00038.svg
> comp00038.svg Type: Scalable Vector Graphics (image/svg+xml)
> Encoding: quoted-printable
>
> ------------------------------------------------------------------------
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-users-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org