You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Max Berger <ma...@berger.name> on 2007/07/24 21:09:06 UTC
Fonts in JAR files
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: max@berger.name
--
PGP/GnuPG ID: E81592BC Print: F489F8759D4132923EC4
BC7E072AB73AE81592BC
For information about me or my projects please see http://
max.berger.name
Re: Fonts in JAR files
Posted by Vincent Hennebert <vi...@anyware-tech.com>.
Hi Max,
Max Berger a écrit :
> Vincent,
>
> Vincent Hennebert schrieb:
<snip/>
>> Your idea of using manifest.xml looks fine. A quick Google search didn't
>> give me any result regarding a standard way of bundling fonts with Java
>> apps. It looks like you did also search for that before going with the
>> manifest.xml approach. Can you just confirm? We wouldn't like to miss
>> any pure Java standard way.
>
> I could not find one. Aamof, I could not find any standard way to
> include resources in the classpath, and unfortunately the classloader
> does not have any notion of "directory listing".
>
> I have, however, missed the most obvious format: the META-INF/MANIFEST
> file [1]. It can also contain information about the enclosed files and
> its attributes, in pairs such as:
>
> Name: somefont.ttf
> Content-Type: application/x-font
>
> Also, this format is already implemented [2].
>
> [1] http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html
> [2] http://java.sun.com/j2se/1.4.2/docs/api/java/util/jar/Manifest.html
You will use the ClassLoader.getResources method, right?
> I personally prefer the syntax of the manifest.xml file, however for
> standards compliance I now think the plain MANIFEST file would be a
> better solution.
Well, that's up to you, but for sure the MANIFEST syntax is simpler to
write and to parse (not yet another XML format). Perhaps the jar tool
even performs validation on such files before bundling them. If that
were me I would probably go with it 8^)
>> Doing the job in XML Graphics Commons would be good, as the font library
>> should ultimately rely there. But I'm not sure if this will be easy to
>> do without moving the whole font stuff now. If that causes you any
>> problem stay in the FOP codebase.
>
> My idea was to have a method simliar to this in commons:
>
> List getResourcesOfMimeType(String mimetype)
>
> where List would be a List<URL>
>
>
> And in FOP:
>
> Font autodetection would then be changed to use URLs instead of Files
> (can handle both files found on disk and in Jars, and avoids loading the
> whole file content), and then simply adding the resources of the known
> font type to the autoconfig list should do the trick.
That looks fine to me.
Vincent
Re: Fonts in JAR files
Posted by Max Berger <ma...@berger.name>.
Vincent,
Vincent Hennebert schrieb:
> Hi Max,
>
> Some general comments. Basically I agree with Andreas and think this
> would be a good addition.
>
> Your idea of using manifest.xml looks fine. A quick Google search didn't
> give me any result regarding a standard way of bundling fonts with Java
> apps. It looks like you did also search for that before going with the
> manifest.xml approach. Can you just confirm? We wouldn't like to miss
> any pure Java standard way.
I could not find one. Aamof, I could not find any standard way to
include resources in the classpath, and unfortunately the classloader
does not have any notion of "directory listing".
I have, however, missed the most obvious format: the META-INF/MANIFEST
file [1]. It can also contain information about the enclosed files and
its attributes, in pairs such as:
Name: somefont.ttf
Content-Type: application/x-font
Also, this format is already implemented [2].
[1] http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html
[2] http://java.sun.com/j2se/1.4.2/docs/api/java/util/jar/Manifest.html
I personally prefer the syntax of the manifest.xml file, however for
standards compliance I now think the plain MANIFEST file would be a
better solution.
> Doing the job in XML Graphics Commons would be good, as the font library
> should ultimately rely there. But I'm not sure if this will be easy to
> do without moving the whole font stuff now. If that causes you any
> problem stay in the FOP codebase.
My idea was to have a method simliar to this in commons:
List getResourcesOfMimeType(String mimetype)
where List would be a List<URL>
And in FOP:
Font autodetection would then be changed to use URLs instead of Files
(can handle both files found on disk and in Jars, and avoids loading the
whole file content), and then simply adding the resources of the known
font type to the autoconfig list should do the trick.
mfG
Max Berger
e-mail: max@berger.name
--
OpenPG ID: E81592BC Print: F489F8759D4132923EC4 BC7E072AB73AE81592BC
For information about me and my work please see http://max.berger.name
Re: Fonts in JAR files
Posted by Vincent Hennebert <vi...@anyware-tech.com>.
Hi Max,
Some general comments. Basically I agree with Andreas and think this
would be a good addition.
Your idea of using manifest.xml looks fine. A quick Google search didn't
give me any result regarding a standard way of bundling fonts with Java
apps. It looks like you did also search for that before going with the
manifest.xml approach. Can you just confirm? We wouldn't like to miss
any pure Java standard way.
Doing the job in XML Graphics Commons would be good, as the font library
should ultimately rely there. But I'm not sure if this will be easy to
do without moving the whole font stuff now. If that causes you any
problem stay in the FOP codebase.
Thanks for your proposal!
Vincent
Andreas L Delmelle a écrit :
> 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
>
>
Re: Fonts in JAR files
Posted by Andreas L Delmelle <a_...@pandora.be>.
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