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=3&rev2=4 Comment: Added the new EnvironmentProfile documentation However, the font-cache isn't made redundant in the CLI use-case since that config doesn't persist. As such we kept the font-cache mechanism albeit with changes to how the font-caching set-up works which will be discussed further. + == The FOP Environment == + + 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. + + 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. + == Questions == Is there a use case for setting properties on the FopFactoryBuilder before parsing the fopConf? - this is a trivial change left out to simplify the API: we would just need to implement new FopConfParser(args..., FopFactoryBuilder) --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
