On Thu, Jan 14, 2016 at 11:29:33AM +0900, Akira TAGOH wrote: > > Then everyone would know: you add a font file? let you run fc-cache. > > We could try to add a boolean flag to the configuration for > enabling/disabiling that check at the runtime though. we definitely > need to test it carefully if it doesn't affect a lot. or only if the > font directory is on nfs. I would call for caution against assuming any nfs-specific behaviour. (For the record, we use Coda file system, not NFS; NFS is not up to the task) Even detecting the use of a somehow "networked" file system is hardly portable and prone to errors. Please do not. There are literally dozens of network file systems with different properties, limitations and bottlenecks. Any application or library specifically checking for a certain file system type(s) is incomplete by design. [Networked filesystems are also a quite complicated field; to be able to properly account for file system specifics one should have the knowledge of a file_system_developer, which most of developers are not. Worse, the behaviours change with versions and implementations. NFSv4 behaves a lot differently than NFSv3, Arla AFS does not behave the same as OpenAFS. In some situations it is stat() which is expensive, in other situation it is open() or lseek() which take a long time, in third situations it is unlink() which should be avoided, and so on.] > > Not sure why the generation would have to be done in advance? > > Because fontconfig on running applications will tries to update the > cache when it is detected. If we end the contract allowing runtime updates, then we are safe. > > If the cache files are being replaced atomically, they only become > > inconsistent if a font file has been removed. Otherwise, applications > > at rescan notice new caches and hence the added fonts as well, > > everything remains fine all the time. Or do I miss something? > > Depends. if fonts has critical changes (e.g. urw-fonts removed > Cyrillic glyphs from Century Scroolbook L) or renaming family name > etc, you'll see inconsistency between caches and fonts. I see, there are more cases when this leads to breakage, than a removal of a font file, but I do not feel that they are crucial. The changes like you describe are usually done not by the users but by system packagers, who already do run fc-cache. In any case, the possible breakage is limited in time, until fc-cache is run. > there are no way to know in advance what fonts are actually being > used. To get rid of the runtime cache generation, we need to have any > way to ensure that caches keeps up-to-date when fonts is > installed/updated. Exactly. IMHO documentation is the best means here, stating that fc-cache has to be run after any change in the font collections, the requirement becoming mandatory, say, 2018-01-01. Putting this in the man page(s) and in the Changelog looks like a fair approach to a change - with either my system packager hat or my user hat on. Of course, having a configure switch to disable the run time generation would be very welcome, to let the distros/packagers make the transision as early as they may wish. Half way from now the switch could change the default from "off" to "on" and at the end of the announced period the switch and the corresponding runtime generation code could be removed. Thanks Akira for your work on fontconfig. Regards, Rune _______________________________________________ Fontconfig mailing list Fontconfig@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/fontconfig
