Dear Wiki user, You have subscribed to a wiki page or wiki category on "Xmlgraphics-fop Wiki" for change notification.
The "FopFactoryConfiguration" page has been changed by Mehdi Houshmand: http://wiki.apache.org/xmlgraphics-fop/FopFactoryConfiguration?action=diff&rev1=4&rev2=5 Comment: Amendments to the new FOP configuration mechanism == Single configuration, single run == - Currently FOP trunk reads the "generic" information when the FopFactory is instantiated, but postpones the reading of renderer specific configuration until it is necessary (i.e. when a FOP run is invoked). The configuration information isn't cached, so the renderer-specific config info is read on every FOP run. This isn't a major problem on the command-line however, in an embedded environment this can be costly. Presumably, some of this cost was mitigated by creating a font-caching system. However, in a highly restricted environment, FOP may not be allowed to create serialized caches in a temporary place for a variety of reasons. + Currently FOP trunk reads the "generic" configuration (i.e. non-renderer specific config) when the FopFactory is instantiated, but postpones the reading of renderer specific config until it is necessary (i.e. when a FOP run is invoked). The configuration information isn't cached, so the renderer-specific config info is read on every FOP run. This isn't a major problem on the command-line however, in an embedded environment this can be costly. Presumably, some of this cost was mitigated by creating a font-caching system. However, in a highly restricted environment, FOP may not be allowed to create serialized caches in a temporary place for a variety of reasons. The solution to this is fairly simple, to redesign the configuration to favour the embedded use-case and allow for the CLI font-caching as well. We have done this by caching all the parsed FOP conf information into an object that is controlled by the FOUserAgent. This is a lazy loaded cache so that the renderer specific config is only parsed when that renderer is invoked, however, once invoked, that specific config will not be parsed again. This has an additional benefit of making the font cache redundant in the embedded use case, since costs of parsing config is only done once in either case. @@ -64, +64 @@ FOP is dependent on the environment it is invoked within, the requirement of system fonts, image libraries and such affect FOP output. The image libraries can't easily be controlled at present, however, system fonts and font detection are controlled by the o.a.f.fonts.FontManager. The font auto-detection mechanism - searching and/or recursing through specifield directories and system directories - use the font-cache to mitigate the performance cost and make the data persist between JVM invocations. These work perfectly fine (not including Batik and SVG fonts) from the CLI, however in more restrictive environments these can be an issue. In a multi-tenant environment, font availability has to be tightly controlled due to licensing restrictions; also users can't be allowed to access non-authorized directories. - As such we have created an EnvironmentProfile that may be given to either the FopConfParser or the FopFactoryBuilder (either of the FopFactory builder classes) which wraps the ResourceResolver, FontManager and base-uri. This object is designed to represent the services and limitations of the environment in which FOP is invoked. The ResourceResolver and base-uri are intrinsically linked to the system since they allow you to control I/O and resource acquisition. The FontManager controls the font caching, auto-detection and system font detection and as such its services are bound to the environment. + As such we have created an EnvironmentProfile that is designed to represent the services and limitations of the environment in which FOP is invoked. This may be given to either the FopConfParser or the FopFactoryBuilder (either of the FopFactory builder classes) which wraps the ResourceResolver, FontManager and base-uri. The ResourceResolver and base-uri are intrinsically linked to the runtime environment and bu allowing clients to control I/O and resource acquisition. The FontManager controls the font caching, auto-detection and system font detection and as such its services are bound to the environment. The FontManager works in the same way as it did previously, except the FontDetector and FontCacheManager can be injected into its constructor (I'm not going to preach the virtues of dependency injection). This allows us to create services that restrict these behaviours by implementing their respective interfaces with whatever restrictions a particular environment needs. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
