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. > I've also found other problems but I haven't fixed them (help welcome) : > -if you have a directory containing fonts.cache-2 file which are not > up-to-date but cache in /var/cache is up to date, running fc-cache will > not remove those fonts.cache-2, even with fc-cache -f. I tried to force > removal of old cache when using -f but doing so would break multiarch > cache (for instance, we run fc-cache -f when upgrading fontconfig > package, to be sure cache is coherent after a fontconfig upgrade). Yeah, I'm not sure what the correct solution to that problem is. I'll have to think about it. > -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? pat _______________________________________________ Fontconfig mailing list Fontconfig@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/fontconfig
