|
Looks like I can replicate the
problem now; its trying to write the cache but the call to get a lock is
failing, this code: FcDirCacheWrite (FcCache *cache,
FcConfig *config) … if (!FcAtomicLock (atomic)) goto bail3; Is leading to a silent failure
(just returns false), i.e. bail3 gets executed. I’ll try to dig a little deeper,
maybe my Cygwin is not doing locks right or something. Would have been nice if
there was some kind of visible error message about this. (^_^)/ Mike. From:
fontconfig-bounces+mgarvin=bell.net@xxxxxxxxxxxxxxxxxxxxx
[mailto:fontconfig-bounces+mgarvin=bell.net@xxxxxxxxxxxxxxxxxxxxx] On Behalf
Of Michael Garvin Some additional detail; I set FC_DEBUG=8063
and ran an unmodified version of fc-cache: FC_DEBUG=8063
Loading config file /etc/fonts/fonts.conf … cache scan dir
/usr/share/fonts/Type1 using FreeType family
"Utopia" using FreeType style "Bold
Italic"
Type1 weight Bold maps to 200
Style Bold Italic maps to width -1
Style Bold Italic maps to slant 100
Style Bold Italic maps to decorative 0 font charset
0000: 00000000 ffffffff ffffffff 7fffffff 00000000 ffffffff ffffffff ffffffff
0001: 00000000 00020000 000c0006 61000003 00040000 00000000 00000000 00000000 … <does the build up of the
font cache for that directory in memory> …. charsets 29 -> 4 leaves 251
-> 24 FcDirCacheWriteDir dir
"/usr/share/fonts/Type1" file "/home/Mike/.fonts.cache-2/d62e99ef547d1d24cdb1bd22ec1a2976-x86.cache-3" /usr/share/fonts/Type1: failed
to write cache Fc Memory Usage:
Which
Alloc
Free Active
count bytes count bytes
count bytes
charset 3970 74626
3970 32362 0 42264 Some how (not sure how), it is
managing to get through to the section of code where it actually tries to write
out to disk. But…that is failing as well. I’ll dig deeper to see if
I can identify why the default Cygwin binary is getting to that stage and the
one compiled from source is not. I think the Cygwin one might be patched
somehow. Still fails though L (^_^)/ Mike. From: fontconfig-bounces+mgarvin=bell.net@xxxxxxxxxxxxxxxxxxxxx
[mailto:fontconfig-bounces+mgarvin=bell.net@xxxxxxxxxxxxxxxxxxxxx] On Behalf
Of Michael Garvin Hi, I’ve been trying to fix the problem with all of my
Cygwin (Widnows XP) Gtk and Qt applications being slow (taking about 5minutes
to startup). I’ve been able to verify that the issue is due to Freetype
being used, and in turn; font-config being used to list off the available fonts
on startup. The problem is that font-config never actually caches anything, so
any font-config using application, has the same (realliy bad) start up
time…every time. I tried running fc-cache manually but to no avail; I double
checked time stamps, having write permission any problems with the
configuration file, bad install of the Cygwin packages etc, but no matter what,
fc-cache always fails on all possible font directories with: failed to write cache After googling around trying all the suggested solutions,
nothing was helping, and I ran strace and looked through the detailed system
calls. It turns out fc-cache tries to open cache files in read only mode.
Which means there is no way it can create cache files L So, I downloaded the source, compiled it up and added printf
statements throughout the call chain from scanDirs() downwards, and picked a
single directory to try and cache (the Type1 fonts directory for Cygwin).
This is what I see: bash-3.2$ ./fc-cache.exe --force --really-force
/usr/share/fonts/Type1/ X: FcDirCacheValid /usr/share/fonts/Type1 X: FcDirCacheValidConfig calling through to
FcDirCacheProcess X: FcDirCacheProcess cache_base=/d62e99ef547d1d24cdb1bd22ec1a2976-le32d8.cache-3 X: FcDirCacheProcess
cache_hashed=/home/Mike/.fonts.cache-2/d62e99ef547d1d24cdb1bd22ec1a2976-le32d8.cache-3 X: opening
/home/Mike/.fonts.cache-2/d62e99ef547d1d24cdb1bd22ec1a2976-le32d8.cache-3
O_RDONLY | O_BINARY X: FcDirCacheProcess fd=-1 /usr/share/fonts/Type1: failed to write cache bash-3.2$ The X: … lines are my printf statements I added to the code.
I looked through the code by hand, from main(), to
scanDirs() and downwards, there is no possible way that I can see for fc-cache
to actually create caches on disk. The code that prints out the
failed to write cache message is just calling FcDirCacheValid(), but this
function is not used to create cache files (the error message of “write failed
is meaningless), only to open then and check that they are valid (hence strace
shows opening of cache files in read only mode with no creat flag..consistent
at least). So from what I can tell, fc-cache is not the program to use
to populate the font caches the very first time. My question is, what program do I use? Can you update
your documentation to correctly point to the right program to use? This has been very frustrating to try and track down.
I guess when I have time next, I’ll try to understand the “init” call
tree that actually does call the functions which build cache files
(FcDirCacheScan), and maybe write a little program that specificalliy calls
those functions so I can get my caches populated, but I really don’t think I
should have to do that. fc-cache should work as its manpage says L (^_^)/ Mike. Michael Garvin |
_______________________________________________ Fontconfig mailing list Fontconfig@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/fontconfig
