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.

Reply via email to