Hi Tor, that's a known problem. FOP's current font infrastructure does not split font metrics (static) and font subset information (dynamic per document). That's the biggest obstacle to making auto-detection not repeat itself for every new document.
On 19.10.2010 23:08:09 Tor-Einar Jarnbjo wrote: > Hi, > > I'm using FOP 1.0 in a situation where it would be most convenient to > load font files from the application's classpath. Adding an auto-detect > element to the font configuration enables this functionality and FOP is > able to find my fonts, after I declared the content type for the font > files in the manifest file. > > After enabling the auto-detect feature, the creation of a new Fop > instance with the factory's newFop method turns out to be very slow > (appr 400ms with font caching enabled, 2.500ms with the cache disabled). > I've debugged the code and it seems as if both the system font diretory, > as well as all manifest files in the classpath are scanned for suitable > fonts every time I create a Fop instance. On Windows, this even means > that Fop starts a new cmd.exe process just to read an environment > variable! Enabling font loading from the classpath without searching the > system font directory as well is obviously not possible, since both > features are enabled with the same configuration option ... > > Shouldn't the font cache be initialized when creating the FopFactory > (here the penalty is acceptable), so that each created Fop instance > could use the factory's font cache? Or am I doing something wrong? > > Regards, > Tor Jeremias Maerki --------------------------------------------------------------------- To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
