DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUGĀ· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=41831>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED ANDĀ· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=41831 ------- Additional Comments From [EMAIL PROTECTED] 2007-03-15 10:28 ------- (In reply to comment #8) > > It is good that you are a Mac user as I was unable to test on the Mac. The > Mac > native font finder should examine the following folders (not recursively) in > order to search for available system fonts :- > > "~/Library/Fonts/", // user > "/Library/Fonts/", // local > "/Network/Library/Fonts/", // network > "/System/Library/Fonts/", // system > "/System Folder/Fonts/" // classic Only local and system worked with me. FOP claimed the other three didn't exist, but: -> user: the ~ does not get resolved correctly; "/~/Library/Fonts" indeed does not exist, since I have no directory "/~", that is "cd /~" doesn't work. I think if you could somehow avoid the slash from being prepended, then it would work. -> network: the Library alias exists with me, but the corresponding device [/automount/Library] is not mounted... -> classic: indeed does not exist, but I think we don't even need to consider supporting Classic anymore. The latest available JVM for that platform was 1.2, IIRC, so if we consider 1.4 as minimal target JVM for the next release, FOP wouldn't run on it anyway. > > The fonts should only be loaded the first time you run FOP in autodetect and > cache mode. After this first run, all the font info should be stored in the > fop.cache (should be created in fop/conf/fop.cache) and subsequent FOP > executions should make use of the cache. Good point. I was only thinking about a recent post on fop-users@ where Abel Braaksma pointed out that loading a 23MB font-file into memory just to use one or two characters was slight overkill. I agree with his point, and I would certainly want to avoid blindly loading three or four of these fonts into memory if they aren't used at all. Besides that, it's not even during the property-resolving stage that the font needs to be loaded. All the FO tree needs to know is whether the supplied font exists in the specified style/weight. It's only during layout that more info about the font is needed (metrics, kerning pairs...). If the FO isn't valid, then the font never needs to be loaded. I agree with the point that FOP only needs to determine the first time whether a font /exists/ and store that info in a cache, but if no document ever uses that font, it should never be loaded completely, which is exactly what fop.fonts.truetype.FontFileReader does behind the scenes, when you call loadFont (). Maybe fop.fonts.LazyFont can be used for this. It seems to fit the purpose, no? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.