On 04/18/2012 09:19 AM, mehdi houshmand wrote:
Hi Rob,
Ooohh, my bad. I must have misunderstood your
concern. This is an interesting little problem,
the only thing I can think if is that the
FopFactory overrides the
FontManager.setFontBaseURL(...) method:
this.fontManager = new FontManager() {
/** {@inheritDoc} */
@Override
public void setFontBaseURL(String fontBase) throws MalformedURLException {
super.setFontBaseURL(getFOURIResolver().checkBaseURL(fontBase));
}
};
But then, you're calling the
"setFontBaseURL(...)" method on FopFactory and not
FontManager, so I don't know, maybe someone else
may have an idea. But could you give us all the
usuals, what version of FOP you're using? Have you
tried seeing if trunk has the same issue etc...
Mehdi
On 18 April 2012 15:39,
Rob Sargent
<rsargent@xmission.com>
wrote:
Thanks
Mehdi, looking forward to the API change.
But I'm not sending ".../acres install/...",
rather (I believe) I'm sending
".../acres%20install/..." as the string
URL. Is that not the correct format?
rjs
On 04/18/2012 01:43 AM, mehdi houshmand
wrote:
Hi Rob,
Firstly, we are working to change
how fop handles file access and I/O
in general. I should note, that
we're unifying all resource
acquisition to resolving URIs, not
URLs. The two concepts differ, and
it's non-trivial.
Secondly, there are some
misnomers in the names of these
resource finders. The issue you're
seeing is that "/d1/rework/acres
install/ac47/eclipe/plugins" while
it is a valid URL, it is not a valid
URI. The
FopFactory.setFontBaseURL(...)
method delegates to the
FOURIResolver to validate the String
given and parses it as a URL NOT a
URL. That is why you're seeing this
problem.
Mehdi
On 17 April
2012 23:58, Rob Sargent
<rsargent@xmission.com>
wrote:
Seems to
me
FopFactory.setFontBaseURL(String
s) is broken?
Forgive the reflection calls
(long story).
File fontsdir = new
File(bundlePath + fopHome +
"/fonts");
URL fontsURL =
fontsdir.toURI().toURL();
setFontBaseURLMethod.invoke(fopFactory,
fontsURL.toExternalForm());
works fine when the
directory is, shall we say,
normal, but if the directory
has a space the method
appears to eat the "%20".
Caused by:
java.net.MalformedURLException:
Illegal character in path at
index 23: file:///d1/rework/acres
install/ac47/eclipse/plugins/com.amirsys.console_4.6.0/fop/fop100/fop/fonts/
bundlePath=/d1/rework/acres
install/ac47/eclipe/plugins
fopHome=com.amirsys.console_4.6.0/fop/fop100/fop
I've written a test jig to
see what
File.toURI().toURL() does:
import
java.net.URL;
import
java.io.File;
public class
FileURL {
public static
void main(String[] args) {
try {
File f
= new File(args[0]);
URL
furl = f.toURI().toURL();
System.out.println(furl.toString());
System.out.println(furl.toExternalForm());
}
catch
(java.net.MalformedURLException
mue) {
mue.printStackTrace();
}
}
}
And that reports what I
expected, an encoded path:
java -cp .
FileURL /d1/rework/acres\
install/ac47
file:/d1/rework/acres%20install/ac47/
file:/d1/rework/acres%20install/ac47/
I hope someone has a
better plan.
I do think that the FOP api
should be changed to take a
URL rather than a string,
but that's for another day.