The example provided by bug 49516 cannot be run with the current trunk. The console error is this when generating PDF: SVG graphic could not be built. Reason: org.apache.batik.bridge.BridgeException: Unable to make sense of URL for connection org.apache.batik.bridge.BridgeException: Unable to make sense of URL for connection The resulting PDF document does not include the SVG. This was not the case in FOP-1.0, where the generated PDF would include the SVG.
I suspect this issue relates to the recent changes made to the URI resolver. After comparing both FOP 1.0 and Trunk I found the main difference stemmed from line found at [trunk]URIResover.getNode:114. It is comparing two ParsedURL's where on trunk they do not match match, however on 1.0 they do which results in a value being returned and different paths being followed. The differences in the ParsedURL's are due to one being passed with just the filename e.g. (trunk) setpaint.svg whereas the other is being passed the full path: (1.0) file://home/user/temp/setpaint.svg This stems from ImageSource.java:123 which accepts the uri. Both make a call to the FOUserAgent.resolveURI() but whereas 1.0 appended the path to the source, the new code does not and simply leaves it as just the name. The reason for the exception is that down the line, due to there being no defined protocol, the ParserURLDefaultProtocolHandler.java:302 then defines the parseURL as a null:setpaint.svg and thus causes a MalformedURLException. The next steps would be to investigate why the baseURL() is no longer being appended to the Source object as that seems to possibly be the source of the problem.
The recent changes to URI handling don't affect FOP1.1, I could be wrong but they haven't been merged into 1.1rc1... Hubris is a cruel mistress though, hope I don't eat my words ;)(In reply to comment #1) > I suspect this issue relates to the recent changes made to the URI resolver. > After comparing both FOP 1.0 and Trunk I found the main difference stemmed > from line found at [trunk]URIResover.getNode:114. It is comparing two > ParsedURL's where on trunk they do not match match, however on 1.0 they do > which results in a value being returned and different paths being followed. > The differences in the ParsedURL's are due to one being passed with just the > filename e.g. > > (trunk) setpaint.svg > > whereas the other is being passed the full path: > > (1.0) file://home/user/temp/setpaint.svg > > This stems from ImageSource.java:123 which accepts the uri. Both make a call > to the FOUserAgent.resolveURI() but whereas 1.0 appended the path to the > source, the new code does not and simply leaves it as just the name. The > reason for the exception is that down the line, due to there being no > defined protocol, the ParserURLDefaultProtocolHandler.java:302 then defines > the parseURL as a null:setpaint.svg and thus causes a MalformedURLException. > > The next steps would be to investigate why the baseURL() is no longer being > appended to the Source object as that seems to possibly be the source of the > problem.
I think I had a similar issue when upgrading my application to fop trunk. Not setting the system id (in FOUserAgent.resolveURI) for the "data" scheme worked around the issue. I was under the impression that the source of the problem was batik and the recent changes in fop just uncovered that, but that might be different in this case. If anyone wants to take a closer look, I can try to provide an additional test cases.