Hash: SHA1


this may not help, but here's a different approach:

Fop (Trunk) supports fonts in jar-files directly, without the need of
font-metrik files. It also adds general support for fonts described with
an URI rather than a file path, which probably solved the problems you

You will need to add <auto-detect/> to your fop config file, and prepare
special font jars, as described in:


This feature is still little tested, so I would be happy to receive any
feedback, especially in the case of a web application, where classloader
issues surface frequently.


Thomas S. schrieb:
> 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
> base).
> 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
> details...
> The configuration and image-inclusion works with relative URLs, an example
> is:
> 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
> file.
> So the two argument in FOURIResolver.resolve(String href, String base) are:
> href:  
> jar:file:/path_to_jar/file.jar!/path_within_jar/fonts/ttfnewsgothic.xml
> 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
> file:/path_to_file/file.jar!/path_within_jar/fonts/ttfnewsgothic.xml.
> This URL doesn't work, cause it's missing the proper protocol specification
> (jar:).
> 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:
> 195c236
> <                     if (href.startsWith(scheme)) {
> ---
>>                     if (href.startsWith(scheme) && "file:".equals(scheme))
>> {
> 197d237
> <                         if ("file:".equals(scheme)) {
> 206d245
> <                     }
> What do you think?

Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


Reply via email to