xmlgraphics-fop-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <...@jeremias-maerki.ch>
Subject Re: FopFactory#newFop(...) performance with auto-detect enabled for fonts
Date Wed, 20 Oct 2010 05:38:29 GMT
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-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org

View raw message