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