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]
