Hi,
Since fontconfig validates a cache during loading it, you'll see your concern after this change right.
I think we need to implement another way or API etc for that use case and web font support instead of disabling this check. even checking mtime in this case shouldn't be wanted. let me think more.
Thanks,
On Wed, Jul 29, 2015 at 1:41 PM, David Lattimore <dml@xxxxxxxxxx> wrote:
Hi Akira,I have a slightly unusual usage of FontConfig in that I store fonts on a server and get FontConfig to scan them to produce a cache, then transfer the cache to a client which loads it, matches fonts then requests those fonts from the server. Currently in order to load the cache on the client, we create an empty font directory with the same mtime as the font directory on the server. This is already pretty hacky, but it works. I fear with the above change we'd find ourselves creating N dummy files in our client-side "font directory". So if there were some way around these checks, that would be good. Perhaps an API to just load a cache file without needing any font directory at all? I've been meaning to see if I could implement such an API in FontConfig, but haven't gotten to it yet.Thanks,DavidOn 29 July 2015 at 12:31, Akira TAGOH <akira@xxxxxxxxx> wrote:_______________________________________________Hi,I need some comments about making a change in FcCache to work around the kinda race condition in updating caches. please read comments in https://bugs.freedesktop.org/show_bug.cgi?id=69845 for more details of the background.As attached at https://bugs.freedesktop.org/attachment.cgi?id=116870 I'm proposing the change to store the number of files in a directory to FcCache so that fontconfig can detect this fault; AFAICS the number of font files being reported from the cache and the actual one is different and it is same or newer than the mtime of directory so fontconfig doesn't update then.The change itself is quite simple and no extra cost to store it. even if it is going to update the cache by this change, it is supposed to be updated per se. the concern is, it may be likely to happen during running applications.Any other concerns or comment on this change?--Akira TAGOH
Fontconfig mailing list
Fontconfig@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/fontconfig
Akira TAGOH
_______________________________________________ Fontconfig mailing list Fontconfig@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/fontconfig
