Nick Alcock <nick.alcock@xxxxxxxxxx> writes: > However, users who add fonts on their own would definitely *not* know, > and programs that do it are not currently explicitly running fc-cache, > so there'd be a big installed base problem to deal with. Agreed, hence why I'd argue that we cannot simply change this by fiat. I'm not sure we can ever do this and not end up with a flag day where some applications simply stop working until fixed, and that's a terrible thought. This was one of fontconfigs first design points though -- not require any manual steps for installing fonts beyond copying them to a suitable directory. I hope we're able to keep this level of simplicity and reliability going forward by identifying the few cases which don't work and fixing them. Perhaps it might be possible to identifying all of the potential 'threading' issues across multiple simultaneous font cache updates systematically. With this analysis, we should either be able to demonstrate the correct sequence of operations or prove that it simply isn't possible. If that latter proof is provided, then we'd have a strong reason to insist on a flag day and break the promise that fontconfig has offered ever since it was first designed. > I think automated out-of-date cache detection and cache updating must > stay for $HOME. It's only system fonts that are problematic for me > (though even for $HOME we need to avoid mega-statting, as now, and we > *also* need to be robust against filesystems with coarse-granularity > timestamps. Both of these behaviours currently appear to be broken.) There used to be an explicit 'sleep' when updating caches to avoid problems with such file systems; perhaps that's insufficient? -- -keith
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Fontconfig mailing list Fontconfig@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/fontconfig
