I already posted this message in the fop-user list, but I think it's better
placed here, cause now
I think it's not a usage problem.

I use Apache FOP 0.94 to include Truetype-fonts into PDFs, which works
perfectly, if the needed
configuration and  font description files are placed in a directory within
file system, but for usage
within a web application I pack these files into a JAR file, and this causes
problems, which I
suppose to be in method 
public Source org.apache.fop.apps.FOURIResolver.resolve(String href, String
Reading the configuration and including images from the JAR still works, but
loading the font metric
unfortunately not.

I also tried 0.95beta with same result, and the implementation of the
relevant code in trunk seems
to be unchanged between rev. 567305 (tag for 0.94) and trunk, so this
applies also for trunk
version. All mentioned line numbers refer to 0.94 / rev. 567305. Now for the

The configuration and image-inclusion works with relative URLs, an example
href:   image/header.png
base: jar:file:/path_to_jar/file.jar!/path_within_jar/

This works without a problem!

But when a font within the XSL-FO processing has to be loaded, the method
FOURIResolver.resolve(String href, String base) is indirectly called from
LazyFont.load() line: 79, now href is an absolute URL to the font metrics

So the two argument in FOURIResolver.resolve(String href, String base) are:
base: jar:file:/path_to_jar/file.jar!/path_within_jar/

The problem is, that lines 194-196 remove "jar:" from href, and we run into
the problem,
that in line 208 the constructor new URL(URL basURL, String href) is called
with a href still containing a protocol (file:), which is different from the
protocol of the
baseURL (jar:), so absoluteURL = new URL(baseURL, href) sets
absoluteURL to
This URL doesn't work, cause it's missing the proper protocol specification

I have to admit, that I don't understand, what lines 197-203 should do (Ok,
we prepend a slash to
the url, if there is a colon and a slash in the url, and the colon is places
before the slash, but why?),
so I cannot give a proper solution for that problem.

But if it's not needed to remove the scheme from the url, if scheme isn't
"file:" (cause only for this
scheme, the slash is prepended), this diff whould help:

<                     if (href.startsWith(scheme)) {
>                     if (href.startsWith(scheme) && "file:".equals(scheme))
> {
<                         if ("file:".equals(scheme)) {
<                     }

What do you think?
View this message in context: 
Sent from the FOP - Dev mailing list archive at Nabble.com.

Reply via email to