Le lundi 09 janvier 2006 à 21:06 +0700, Patrick Lam a écrit : > Frederic Crozat wrote: > > Hi, > > > > the new cache location code has introduced new bugs in fontconfig : > > -when using fc-cache . in a directory, the string used to generate > > md5sum key is always "./fonts.cache-2" which will collide if the same > > command is run in several directories. > > -a similar problem happen when using : fc-cache /foo/bar and > > fc-cache /foo/bar/ : strings used to generate md5sum are not the same, > > resulting in different cache. > > > > The attached patch fixes the issue. > > I've committed my patch. 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 ;) > > -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. -- Frederic Crozat <fcrozat@xxxxxxxxxxxx> Mandriva _______________________________________________ Fontconfig mailing list Fontconfig@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/fontconfig
