Just to finish up on this, I need to do a release of my jDocBook plugin for maven and I need to make use of this functionality. So I need to make use of FOP 0.95++.
First obvious question is when is 0.96 expected? Second, I can do a "snapshot" build of FOP from the sources I have here. For the lib/xmlgraphics-commons-1.4svn.jar, was there a particular tag from which that was pulled and built? On Mon, 2009-06-15 at 23:59 +0200, Andreas Delmelle wrote: > On 15 Jun 2009, at 23:33, Steve Ebersole wrote: > > > I am debugging through the code right now. I am currently looking at > > FontCache. I was not expecting cache hits, I did not realize that the > > cache was persistent. > > Yes. I'm still not /completely/ up to speed as to what happens there, > but that I know for certain. Obviously, we want to avoid, as much as > possible, to open/read the font-file each and every time the font is > referenced. In fact, it goes so far that, if a font-file has failed to > load *and* the cache is not invalidated/deleted, the file will never > be checked again, except for the modification timestamp. FOP will only > retry parsing if the FontCache's serialVersionUID has been modified, > or the physical file appears more recent than the one that failed to > load. > > <snip /> > > Which brings up the question about guidelines for programatic use of > > FontCache.load(). Do I use it, and just tell my users to delete that > > cache file if they encounter problems? Do I add an option to clear > > the > > font cache? Do I just not use it? > > That's entirely up to you. For regular embedded usage, if you want to > be absolutely sure that all the info is reconstituted from scratch, > the 'useCache' option on the FontManager allows you to do just that. > In your case, the fact that FontInfoFinder only does something with > the FontCache if it is non-null could be used to the same end. > There is obviously a price to pay in terms of processing time > (increased/repeated disk I/O) > I think the cache offers a significant benefit in a good deal of > common use-cases, so I'd personally only disable it after repeatedly > running into problems. > > > Regards > > > Andreas > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > -- Steve Ebersole <[email protected]> Hibernate.org --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
