A file:// url in the <base> element in fopconfig.xml must end with a slash on Linux. If it does not, images (specified by "url(foo)" where foo is a relative file name) won't be found and will thus not be added to the PDF. FOP should probably either accept both ways to specify the url or display an ERROR that refers to this setting. This would make it much easier to debug this problem.
(In reply to comment #0) > A file:// url in the <base> element in fopconfig.xml must end with a slash on > Linux. If it does not, images (specified by "url(foo)" where foo is a relative > file name) won't be found and will thus not be added to the PDF. FOP should > probably either accept both ways to specify the url or display an ERROR that > refers to this setting. This would make it much easier to debug this problem. Well, this is the normal behavior of URLs (and more generally URIs). When resolving a relative reference against a base URI, all the characters of the base URI which are to the right of the rightmost slash are removed, and replaced by the relative path: file://path/to/images + myImage.png -> file://path/to/myImage.png file://path/to/images/ + myImage.png -> file://path/to/images/myImage.png So the ending slash is important! The best Fop can do IMO is display the full resolved URI in the error message, so that the user immediately sees that there is something wrong with URI resolution.
Hey, I didn't want to change the severity of this bug! Sorry :-\
Displaying the full URL in the error message sounds like a good solution to me.
This bug should be fixed/addressed by [PATCH] http://issues.apache.org/bugzilla/show_bug.cgi?id=41514
The full URL isn't yet displayed when the resolution of a resource failed.
Created attachment 19603 [details] logs full url - not just relative part if there is a failed resolution
Comment on attachment 19603 [details] logs full url - not just relative part if there is a failed resolution Index: C:/workspace/fop/src/java/org/apache/fop/apps/FOURIResolver.java =================================================================== --- C:/workspace/fop/src/java/org/apache/fop/apps/FOURIResolver.java (revision 507572) +++ C:/workspace/fop/src/java/org/apache/fop/apps/FOURIResolver.java (working copy) @@ -155,7 +155,7 @@ //Note: This is on "debug" level since the caller is supposed to handle this log.debug("File not found: " + effURL); } catch (java.io.IOException ioe) { - log.error("Error with opening URL '" + href + "': " + ioe.getMessage()); + log.error("Error with opening URL '" + effURL + "': " + ioe.getMessage()); } return null; } @@ -202,6 +202,9 @@ * @returns the base URL as java.net.URL */ private URL toBaseURL(String baseURL) { + if (!baseURL.endsWith("/")) { + log.warn("Base url does not end with a '/'. This could cause resolution problems"); + } try { return new URL(baseURL == null ? new java.io.File("").toURL().toExternalForm()
Created attachment 19604 [details] logs full url - not just relative part if there is a failed resolution not warns about base urls not ending with '/' chars
Not sure I like the warning. There is no requirement for a base URL to end with a /.
Created attachment 19607 [details] logs full url - not just relative part if there is a failed resolution Ammends base url as necessary with trailing '/'. I can't think of any reason/instance when you would want to lose the end part of your base url because you neglected to append a trailing slash.
(In reply to comment #10) > Created an attachment (id=19607) [edit] > logs full url - not just relative part if there is a failed resolution > > Ammends base url as necessary with trailing '/'. I can't think of any > reason/instance when you would want to lose the end part of your base url > because you neglected to append a trailing slash. Patch applied with some modifications. Thanks Adrian! Please leave bugs open when submitting patches. We will close them when applying the patches. I re-open this bug because the problem isn't entirely solved yet. The full URL doesn't appear in strict user config validation mode. Also, when I specify a wrong base-font URL (pointing to a non-existing directory), this throws a catched FileNotFoundException (FOURIResolver.java, l.159), and null is returned. Thus FontSetup displays an error message (or throws a ConfigurationException) with the relative URL (FontSetup.java, l.291). Vincent
Isn't a full URL, that is a URL pointing to a file resource a legal base URL which will now fail? For example if I set the base URL to the file I am processing, lets say 'file:///home/mm/test.xml' the previous version would accept that and resolve references relative to that while now we are appending a / and it will fail.
(In reply to comment #12) > Isn't a full URL, that is a URL pointing to a file resource a legal base URL > which will now fail? For example if I set the base URL to the file I am > processing, lets say 'file:///home/mm/test.xml' the previous version would > accept that and resolve references relative to that while now we are appending a > / and it will fail. Indeed, and I was also concerned by that at the beginning. But that code is used only to handle the <base> and <font-base> elements in the user config file, where it would be really unusual to see URLs pointing to files instead of directories. And anyway such cases would happen with power users having a good understanding of relative URL resolution. If they have the full URL in the error message, they will understand that they have to remove the last part of it to make the thing work. So this change looks safe to me. Now if a majority of the developers have concerns about that I can revert it. We can also move that piece of code to the place where base/font-base are retrieved. WDYT? Vincent
Admittedly I haven't looked at the code in detail but wouldn't the same logic apply when setting the base URL programatically. I can easily envisage an environment where the XML/FO to process comes from some source whose location varies and the programmer dynamically sets the base URL to the input file in question. It boils down to that a base URL is something different than a base directory or base file system path. I would prefer to strengthen our documentation, add appropriate comments to our sample config file and may be add a hint as part of the error message compared to making a FOP base URL meaning something different than in the rest of the URL resolution world. But in the end its really a very minor issue and I be happy to go with whatever the FOP committer majority prefers.
resetting P2 open bugs to P3 pending further review