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 <rsarg...@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.
>
> See http://wiki.apache.org/xmlgraphics-fop/URIResolution and
> http://wiki.apache.org/xmlgraphics-fop/FopFactoryConfiguration.
>
> 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 <rsarg...@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/acresinstall/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.
>>
>>
>>
>
>
