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 > <d...@jeremias-maerki.ch>wrote: > > > I found a potential problem: The <directory> 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 +0000, 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
