Dear FOP-devs,

I would like to add a new feature to fop (past 0.94): The ability to add fonts in .jar files.

Why? Because delivering a font with an application is a real pain in java, as there is no good notion of "application directory". However, loading something from the classpath is fairly easy. This would allow fop to come bundled with fonts, such as dejavu.jar (and hopefully stixfonts.jar - if they are ever release. They have just been pushed back aug 15....). It would also make font handling through mechanisms such as maven repositories possible.

What would be involved? I'd modify the FontAutoDetection to also load Fonts from the classpath. (This unfortunately also involves making it handle streams in addition to files).

The problem: We need a "good format" for font-jars. Indeed, I would like to define a format which could be used in other Java applications (such as foray, JEuclid, etc.) as well.

My first ideas was META-INF/services, however, I do not think this would fit in there well, as this is not an implementation.

I've looked around for standard of resources in jar files, and found the OpenOffice format. It contains data in any directory, and a "META- INF/manifest.xml" file. This file contains information about the other files [1]. I think this format is generic enough. Using this format a jar file could contain:

/somefont.ttf  (can also be in any directory)
/someotherfont.otf
/META-INF/manifest.xml

where manifest.xml would contain:

<?xml version="1.0" encoding="utf-8"?>
<manifest:manifest xmlns:manifest="urn:oasis:names:tc:opendocument:xmlns:manifest:1.0"> <manifest:file-entry manifest:media-type="application/x-font- truetype"
        manifest:full-path="somefont.ttf" />
<manifest:file-entry manifest:media-type="application/x-font- opentype"
        manifest:full-path="someotherfont.otf" />
</manifest:manifest>

Advantages:
- The format is already specified and proven.
- The resource format is generic enough for all kinds of embedded resources, so the functionality could be added to xmlgraphics-common instead.

Disadvantages:
- Another xml-format to parse
- there are no standard mime-types for true-type, opentype, or pfb fonts (the draft for this expired). I am therefore suggesting to support "application/x-font", "application/x-font-truetype", "application/x-font-opentype", and "application/x-font-pfb" (these are the ones I found while used on the net)

I'd even volunteer to do this work :). Plan of action:
- Collect feedback if this is a desirable / undesirable feature
- Collect feedback on format (is manifest.xml a good choice?)
- implement manifest.xml reader in xmlgraphics-commons
- modify font auto detection to use the reader
- test / submit patches

Please comment!

[1] http://books.evc-cit.info/odbook/ch01.html



Max Berger
e-mail: [EMAIL PROTECTED]

--
PGP/GnuPG ID: E81592BC Print: F489F8759D4132923EC4 BC7E072AB73AE81592BC For information about me or my projects please see http:// max.berger.name


Attachment: PGP.sig
Description: Signierter Teil der Nachricht

Reply via email to