On Jul 24, 2007, at 21:09, Max Berger wrote:

Hi Max

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.

This seems like a very worthwhile addition to FOP to me. As far as I dare speak for the others, I have a vague feeling they will very much agree. FOP is a Java application, and as such, the possibility to include fonts in that way fits perfectly in the scope of the project --maybe it's even better situated in XML Graphics Commons.

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).

I don't see an immediate problem there. I used to be against actually loading the fonts soon, but reconsidering since in one of the most widely used contexts --servlets-- many fonts will have been loaded after the first few renderings anyway. It's still probably not a good idea to do this with too many fonts that are never actually used in any documents, though... If I get the font-library code correctly, custom fonts are loaded entirely in memory, so a few big Unicode fonts on the classpath could create an unnecessary amount of overhead if we're not careful.

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)

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" />

- 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.

Heh, hadn't actually read this entirely before making my suggestion higher up. Full of good ideas you are. :)

- Another xml-format to parse
- there are no standard mime-types for true-type, opentype, or pfb fonts (the draft for this expired).

Neither was there one for 'xml/X-fop-areatree', so ...

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)

... these seem good enough.

I'd even volunteer to do this work :).

All the better.

Plan of action:
- Collect feedback if this is a desirable / undesirable feature

Skip this step and start programming! We'll sort out the details later. =)

- Collect feedback on format (is manifest.xml a good choice?)

Good idea. Best poll around a bit for preferences, although your proposal seems quite acceptable to me.

- implement manifest.xml reader in xmlgraphics-commons
- modify font auto detection to use the reader
- test / submit patches

+1 from me.



Reply via email to