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)
/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.
Heh, hadn't actually read this entirely before making my suggestion
higher up. Full of good ideas you are. :)
Disadvantages:
- 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.
Cheers
Andreas
