Re: The base of relative URIs in fop.xconf
On 04 Feb 2011, at 17:40, Glenn Adams wrote: > so if one specifies > > file:///../fop.xml If I understand correctly, while it does not violate the URI syntax, this would not be considered a relative URI either way. That is, java.net.URI will consider it absolute, because it has a scheme component (file://). A URI is relative only if the scheme component is absent. An absolute file path starting at the root is still a relative URI if it is not preceded by 'file://'. It can be resolved against an absolute file: URI, but for other purposes also against an ftp:, http:... > if you are discussing the use of the Java URI class, this is another matter, > but just keep in mind that external specifications of the file URL should > never have a relative path for , and all external specifications of the > form file:///foo.bar refers to the file foo.bar in the root directory (and > not in relationship to some implied xml:base); Very true, and that is exactly how java.net.URI.resolve() operates. If you call it on a URI created for the string "file:///foo.bar", you will simply get the same absolute URI back, no matter which URI you resolve against (xml:base, user-config base...). That said, I believe the issue raised by Jeremias concerns the implicit resolution of relative paths against the current working directory (due to: new File(relativePath)), instead of a possible absolute file URL (font-base?). Regards, Andreas ---
Re: The base of relative URIs in fop.xconf
I'm not sure there is a definition of the file scheme that is not a URL scheme. When 1630 was published, the distinction between URI and URL was not worked out yet. At present, the official definition of the file scheme is shown by IANA to be 1738 (see http://www.iana.org/assignments/uri-schemes.html). In the case of an empty specification, one has: file:/// so if one specifies file:///../fop.xml then this maps (on UNIX) to "/../fop.xml" which is not a legitimate path, or at least it will cause EACCESS or equivalent upon access; if you are discussing the use of the Java URI class, this is another matter, but just keep in mind that external specifications of the file URL should never have a relative path for , and all external specifications of the form file:///foo.bar refers to the file foo.bar in the root directory (and not in relationship to some implied xml:base); at least this is my understanding of the formal definition of "file:" g. On Fri, Feb 4, 2011 at 8:36 AM, Jeremias Maerki wrote: > I'm talking about URIs, not URLs. There's nothing in RFC 1630 that > prohibits relative URIs for the file URI scheme. It's actually > describing relative URIs. The file URIs are eventually resolved to file > URLs which are then absolute. > > On 04.02.2011 15:50:09 Glenn Adams wrote: > > note that the "file:" URL scheme does not technically support relative > URLs; > > however, that hasn't prevented some implementations from making > non-standard > > extensions to provide such support > > > > On Fri, Feb 4, 2011 at 7:08 AM, Jeremias Maerki >wrote: > > > > > I found a potential problem: The Tag in the configuration > > > takes file paths (not URIs, since we can't detect files on arbitrary > > > URIs). FontInfoConfigurator doesn't try to resolve relative directories > > > against the base or font base URI (see #addDirectories() and > > > FontFileFinder.find(String)). So people using relative paths could run > > > into a small problem here. Maybe we need to resolve against the base > URI > > > if the base URI is a file-based URI. > > > > > > On 14.01.2011 14:04:03 Simon Pepping wrote: > > > > Done. Simon > > > > > > > > On Tue, Jan 11, 2011 at 07:40:59PM +0100, Simon Pepping wrote: > > > > > On Tue, Jan 11, 2011 at 10:55:25AM +, Peter Hancock wrote: > > > > > > Hi, > > > > > > > > > > > > When configuring the base directory using the fop.xconf relative > urls > > > > > > are based on the working directory, and not the fop.xconf. > > > > > > This contradicts the URI specification as pointed out in > > > > > > > http://old.nabble.com/Re%3A-Problem-with-custom-fonts-p10013042.html > > > > > > > > > > I hate it when applications show this bug. I was not aware that FOP > > > > > suffers from it. The problem must be solved as soon as possible. > > > > > > > > > > > Can anyone suggest a robust way of achieving this scenario, given > the > > > > > > current limitations of FOP, or should I fix this bug? > > > > > > > > > > It would be wonderful if you can provide a fix. > > > > > > > > > > Simon > > > > > > > > > > > > > > > Jeremias Maerki > > > > > > > > > > > Jeremias Maerki > >
Re: The base of relative URIs in fop.xconf
I'm talking about URIs, not URLs. There's nothing in RFC 1630 that prohibits relative URIs for the file URI scheme. It's actually describing relative URIs. The file URIs are eventually resolved to file URLs which are then absolute. On 04.02.2011 15:50:09 Glenn Adams wrote: > note that the "file:" URL scheme does not technically support relative URLs; > however, that hasn't prevented some implementations from making non-standard > extensions to provide such support > > On Fri, Feb 4, 2011 at 7:08 AM, Jeremias Maerki > wrote: > > > I found a potential problem: The Tag in the configuration > > takes file paths (not URIs, since we can't detect files on arbitrary > > URIs). FontInfoConfigurator doesn't try to resolve relative directories > > against the base or font base URI (see #addDirectories() and > > FontFileFinder.find(String)). So people using relative paths could run > > into a small problem here. Maybe we need to resolve against the base URI > > if the base URI is a file-based URI. > > > > On 14.01.2011 14:04:03 Simon Pepping wrote: > > > Done. Simon > > > > > > On Tue, Jan 11, 2011 at 07:40:59PM +0100, Simon Pepping wrote: > > > > On Tue, Jan 11, 2011 at 10:55:25AM +, Peter Hancock wrote: > > > > > Hi, > > > > > > > > > > When configuring the base directory using the fop.xconf relative urls > > > > > are based on the working directory, and not the fop.xconf. > > > > > This contradicts the URI specification as pointed out in > > > > > http://old.nabble.com/Re%3A-Problem-with-custom-fonts-p10013042.html > > > > > > > > I hate it when applications show this bug. I was not aware that FOP > > > > suffers from it. The problem must be solved as soon as possible. > > > > > > > > > Can anyone suggest a robust way of achieving this scenario, given the > > > > > current limitations of FOP, or should I fix this bug? > > > > > > > > It would be wonderful if you can provide a fix. > > > > > > > > Simon > > > > > > > > > > Jeremias Maerki > > > > Jeremias Maerki
Re: The base of relative URIs in fop.xconf
note that the "file:" URL scheme does not technically support relative URLs; however, that hasn't prevented some implementations from making non-standard extensions to provide such support On Fri, Feb 4, 2011 at 7:08 AM, Jeremias Maerki wrote: > I found a potential problem: The Tag in the configuration > takes file paths (not URIs, since we can't detect files on arbitrary > URIs). FontInfoConfigurator doesn't try to resolve relative directories > against the base or font base URI (see #addDirectories() and > FontFileFinder.find(String)). So people using relative paths could run > into a small problem here. Maybe we need to resolve against the base URI > if the base URI is a file-based URI. > > On 14.01.2011 14:04:03 Simon Pepping wrote: > > Done. Simon > > > > On Tue, Jan 11, 2011 at 07:40:59PM +0100, Simon Pepping wrote: > > > On Tue, Jan 11, 2011 at 10:55:25AM +, Peter Hancock wrote: > > > > Hi, > > > > > > > > When configuring the base directory using the fop.xconf relative urls > > > > are based on the working directory, and not the fop.xconf. > > > > This contradicts the URI specification as pointed out in > > > > http://old.nabble.com/Re%3A-Problem-with-custom-fonts-p10013042.html > > > > > > I hate it when applications show this bug. I was not aware that FOP > > > suffers from it. The problem must be solved as soon as possible. > > > > > > > Can anyone suggest a robust way of achieving this scenario, given the > > > > current limitations of FOP, or should I fix this bug? > > > > > > It would be wonderful if you can provide a fix. > > > > > > Simon > > > > > Jeremias Maerki > >
Re: The base of relative URIs in fop.xconf
I found a potential problem: The Tag in the configuration takes file paths (not URIs, since we can't detect files on arbitrary URIs). FontInfoConfigurator doesn't try to resolve relative directories against the base or font base URI (see #addDirectories() and FontFileFinder.find(String)). So people using relative paths could run into a small problem here. Maybe we need to resolve against the base URI if the base URI is a file-based URI. On 14.01.2011 14:04:03 Simon Pepping wrote: > Done. Simon > > On Tue, Jan 11, 2011 at 07:40:59PM +0100, Simon Pepping wrote: > > On Tue, Jan 11, 2011 at 10:55:25AM +, Peter Hancock wrote: > > > Hi, > > > > > > When configuring the base directory using the fop.xconf relative urls > > > are based on the working directory, and not the fop.xconf. > > > This contradicts the URI specification as pointed out in > > > http://old.nabble.com/Re%3A-Problem-with-custom-fonts-p10013042.html > > > > I hate it when applications show this bug. I was not aware that FOP > > suffers from it. The problem must be solved as soon as possible. > > > > > Can anyone suggest a robust way of achieving this scenario, given the > > > current limitations of FOP, or should I fix this bug? > > > > It would be wonderful if you can provide a fix. > > > > Simon Jeremias Maerki
Re: The base of relative URIs in fop.xconf
Hi Simon, You beat me too it :-) I can confirm it works for a simple case I was considering. Thanks! Peter On Fri, Jan 14, 2011 at 1:04 PM, Simon Pepping wrote: > Done. Simon > > On Tue, Jan 11, 2011 at 07:40:59PM +0100, Simon Pepping wrote: >> On Tue, Jan 11, 2011 at 10:55:25AM +, Peter Hancock wrote: >> > Hi, >> > >> > When configuring the base directory using the fop.xconf relative urls >> > are based on the working directory, and not the fop.xconf. >> > This contradicts the URI specification as pointed out in >> > http://old.nabble.com/Re%3A-Problem-with-custom-fonts-p10013042.html >> >> I hate it when applications show this bug. I was not aware that FOP >> suffers from it. The problem must be solved as soon as possible. >> >> > Can anyone suggest a robust way of achieving this scenario, given the >> > current limitations of FOP, or should I fix this bug? >> >> It would be wonderful if you can provide a fix. >> >> Simon >
Re: The base of relative URIs in fop.xconf
Done. Simon On Tue, Jan 11, 2011 at 07:40:59PM +0100, Simon Pepping wrote: > On Tue, Jan 11, 2011 at 10:55:25AM +, Peter Hancock wrote: > > Hi, > > > > When configuring the base directory using the fop.xconf relative urls > > are based on the working directory, and not the fop.xconf. > > This contradicts the URI specification as pointed out in > > http://old.nabble.com/Re%3A-Problem-with-custom-fonts-p10013042.html > > I hate it when applications show this bug. I was not aware that FOP > suffers from it. The problem must be solved as soon as possible. > > > Can anyone suggest a robust way of achieving this scenario, given the > > current limitations of FOP, or should I fix this bug? > > It would be wonderful if you can provide a fix. > > Simon
Re: The base of relative URIs in fop.xconf
On Tue, Jan 11, 2011 at 10:55:25AM +, Peter Hancock wrote: > Hi, > > When configuring the base directory using the fop.xconf relative urls > are based on the working directory, and not the fop.xconf. > This contradicts the URI specification as pointed out in > http://old.nabble.com/Re%3A-Problem-with-custom-fonts-p10013042.html I hate it when applications show this bug. I was not aware that FOP suffers from it. The problem must be solved as soon as possible. > Can anyone suggest a robust way of achieving this scenario, given the > current limitations of FOP, or should I fix this bug? It would be wonderful if you can provide a fix. Simon
The base of relative URIs in fop.xconf
Hi, When configuring the base directory using the fop.xconf relative urls are based on the working directory, and not the fop.xconf. This contradicts the URI specification as pointed out in http://old.nabble.com/Re%3A-Problem-with-custom-fonts-p10013042.html This can be more than an simple inconvenience when the working directory and the location of the fop.xconf are not related. Here is an example of something I wish to achieve with a set of limitations * I have a directory that contains both a fop.xconf and a directory of resources (fonts etc). * In the fop.xconf I want to reference resources relative to the fop.xconf. * I am unable to change path to the current working directory to coincide with the fop.xconf: e.g I may be running the FOP ant task that uses the location of the ant script as the working directory. * Using absolute paths is not an option since I wish to be able to move the fop.xconf without changing URIs referenced within. Can anyone suggest a robust way of achieving this scenario, given the current limitations of FOP, or should I fix this bug? Thanks, Pete
