Re: The base of relative URIs in fop.xconf

2011-02-04 Thread Jeremias Maerki
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 +, 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

2011-02-04 Thread Glenn Adams
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.chwrote:

 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 +, 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

2011-02-04 Thread Jeremias Maerki
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.chwrote:
 
  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 +, 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

2011-02-04 Thread Glenn Adams
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 host specification, one has:

file:///path

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 path, 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 d...@jeremias-maerki.chwrote:

 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 +, 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

2011-02-04 Thread Andreas Delmelle
On 04 Feb 2011, at 17:40, Glenn Adams wrote:

snip /
 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 path, 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

2011-01-14 Thread Simon Pepping
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

2011-01-14 Thread Peter Hancock
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 spepp...@leverkruid.eu 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

2011-01-11 Thread Simon Pepping
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