In that version, we've tried to prevent the race on updating caches by re-scanning a directory after updating a cache once. which isn't being done on the latest anymore.
On Mon, Aug 29, 2016 at 5:07 AM, Werner LEMBERG <wl@xxxxxxx> wrote:
[fontconfig 2.11.0]
Running
fc-cache -v
as a normal user, I see the following.
/usr/share/fonts: skipping, existing cache is valid: 0 fonts, 11 dirs
/usr/share/fonts/100dpi: skipping, existing cache is valid: 398 fonts, 0 dirs
...
-> /home/wl/.fonts: skipping, existing cache is valid: 56 fonts, 1 dirs
/home/wl/.fonts/texlive: skipping, existing cache is valid: 0 fonts, 3 dirs
/home/wl/.fonts/texlive/opentype: skipping, existing cache is valid: 0 fonts, 12 dirs
/home/wl/.fonts/texlive/opentype/adobe: skipping, existing cache is valid: 0 fonts, 3 dirs
/home/wl/.fonts/texlive/opentype/adobe/sourcecodepro: skipping, existing cache is valid: 14 fonts, 0 dirs
...
-> /home/wl/.fonts: caching, new cache contents: 56 fonts, 1 dirs
...
fc-cache: succeeded
(I've added `fonts/{opentype,truetype,type1}' from a TeXLive
installation as symlinks to `~/.fonts/texlive'.)
What I don't understand are the two marked lines: Why does fontconfig
first report a valid cache, then doing a caching operation inspite of
this?
Werner
_______________________________________________
Fontconfig mailing list
Fontconfig@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/fontconfig
Akira TAGOH
_______________________________________________ Fontconfig mailing list Fontconfig@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/fontconfig
