u-pnrz@xxxxxxxx writes: > I would rather postulate fc-cache to be run and risk ignoring some fonts > until this is done. Is the risk really significant? Distros run fc-cache, > users who add fonts on their own would know they have to run fc-cache. Yes, it's pretty clear we've gotten distros to understand that running fc-cache is required after installing fonts. > What makes me unconfortable is applications doing huge i/o operation at > startup just because of a certain library being used. Then neither > the application developer nor the user have some real power over the > behaviour. It's failures within fontconfig that cause this > I would be even more uncomfortable if there will be some locks involved > or some daemons would be expected to run just to be able to rely on > fontconfig. Explicit cache creation looks like the cleanest solution. Here's another alternative -- cache creation could be the responsibility of fc-cache, but perhaps applications could validate the cache by checking directory timestamps and loading directories which were out of date manually (as they do today) but *not* write out that information back to the disk which would avoid the race conditions present in the current environment. fc-cache could then use some kind of per-directory locking to avoid races in generating the information there, which should make the directory timestamps reliable enough to not need applications to scan every directory manually at startup time. -- -keith
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Fontconfig mailing list Fontconfig@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/fontconfig
