DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=36082>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=36082 Summary: [PATCH] Relative URIs are not correctly resolved Product: Fop Version: 1.0dev Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: general AssignedTo: fop-dev@xml.apache.org 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 external image. 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.
