[Fontconfig] Patch: fix for fc-cache with relative path
plam at MIT.EDU
Tue Jan 10 05:21:49 PST 2006
Frederic Crozat wrote:
> Good, I'll test it later this week. I knew about realpath ugliness but I
> couldn't figure a good way to replace it (too bad fontconfig doesn't use
> glib ;)
The patch I committed earlier was slightly broken, but I think I've
fixed it now.
>>>-in some directories containing only ttf fonts, running fc-cache -v
>>>again and again always regenerate the cache (which is strange, since the
>>>directory was not modified at all).
>>>-this last bug is causing huge delays when starting applications for the
>>>first time after running fc-cache as root, since cache is detected as
>>>dirty and fontconfig regenerates it for the user (and on my test system,
>>>I have two big chinese fonts of 20MB and 16MB ...).
>>Do you have any more hints on when these problems occur?
> Those two patches are no longer reproducible after removing all files
> in /var/cache/fontconfig and re-running fc-cache with my "realpath"
> patch. I guess old broken cache where causing this. People which were
> reporting similar issues on cooker confirmed it fixed it.
> I guess your similar fix will have a similar effect.
Actually, I figured out what caused this: the directory cache contains
the absolute path, but fc-cache . will try to open a cache for path '.',
which fails. This works now.
More information about the Fontconfig