DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Summary: [PATCH] Relative URIs are not correctly resolved
ReportedBy: [EMAIL PROTECTED]
Jeremias wrote on fop-dev: Basically, I've stumbled upon a few anomalies with
relative paths and resource access in general. Images were not properly loaded
and I think there were differences in behaviour between FOP and Batik.
The problem can be easily reproduced by running fop from a different directory
as the fo/xml input file and the input file has a relative URI reference to an
The problem is caused by the FOUserAgent.getBaseURL() method always returning a
URL even if it is not set and the InputHandler.render() method only setting the
base URL in the FOUserAgent if getBaseURL() returns null which it never does.
The attached patch fixes that by making getBaseURL() returning null if no
baseURL is set. Doing this on its own would have lost the functionality of
defaulting the baseURL to the current directory if not set. I therefore added a
function getBaseURLasURL to FOUserAgent which returns the current baseURL as a
java.net.URL and defaults that to a file: URL pointing to the current directory
if baseURL is not set. It also ports some URL normalisation code for relative
URLs from 0.20.5 FopImageFactory to ImageFactory.
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.