cachedir is used to determine where cache files are stored.
the empty directory will ends up to put them under the top of
directory of XDG_CACHE_HOME. that messes it up and must be avoided.
As a note, if you want to read/write something from the top of
XDG_DATA_HOME (dir) and/or XDG_CACHE_HOME (cachedir),
put "." instead of the empty.
https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/180
Currently it fails if the executable extension is .exe, but wine isn't
available (e.g. on Cygwin)
Possibly the check to use this wrapper should be even more restrictive
e.g. checking if cross-building and/or if wine is available.
'salt' attribute affects a cache filename to generate different name from directory name.
This is useful when sharing caches with host on sandbox and/or give a filename differently:
<dir salt="randomdata">/usr/share/fonts</dir>
<remap-dir as-path="/usr/share/fonts" salt="salt for /usr/share/fonts on host">/run/host/fonts</remap-dir>
Applications can read caches as-is for fonts on /run/host/fonts where is mounted from host.
and write a cache for their own fonts on /usr/share/fonts with different name.
The UUID files would be placed in each font directory to provide the
unique cache name, independent of path, for that directory. The UUID
files are undesireable for a couple of reasons:
1) They must be placed in the font directories to be useful. This
requires modifying the font directories themselves, introducing
potential visible timestamp changes when running multiple
applications, and makes the cache processing inconsistent between
applications with permission to write to the font directories and
applications without such permission.
2) The UUID contents were generated randomly, which makes the font
cache not reproducible across multiple runs.
One proposed fix for 2) is to make the UUID dependent on the font
directory path, but once we do that, we can simply use the font
directory path itself as the key as the original MD5-based font cache
naming mechanism did.
The goal of the UUID file mechanism was to fix startup time of
flatpaks; as the font path names inside the flatpak did not match the
font path names in the base system, the font cache would need to be
reconstructed the first time the flatpak was launched.
The new mechanism for doing this is to allow each '<dir>' element in
the configuration include a 'map' attribute. When looking for a cache
file for a particular directory, if the directory name starts with the
contents of the <dir> element, that portion of the name will be
replaced with the value of the 'map' attribute.
Outside of the flatpak, nothing need change -- fontconfig will build
cache files using real directory names.
Inside the flatpak, the custom fonts.conf file will now include
mappings such as this:
<dir map="/usr/share/fonts">/run/host/fonts</dir>
When scanning the directory /run/host/fonts/ttf, fontconfig will
use the name /usr/share/fonts/ttf as the source for building the cache
file name.
The existing FC_FILE replacement code used for the UUID-based
implementation continues to correctly adapt font path names seen by
applications.
v2:
Leave FcDirCacheCreateUUID stub around to avoid removing
public API function.
Document 'map' attribute of <dir> element in
fontconfig-user.sgml
Suggested-by: Akira TAGOH <akira@tagoh.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
On a file system with one-second time stamps, extra delays are needed
between cache modification operations to ensure that fontconfig isn't
fooled.
And, when the timestamps are checked correctly, we need to make sure
that FcConfigUptoDate returns false whenever we change a font
directory, so separate that out from the call to reinitialize the core
config.
Signed-off-by: Keith Packard <keithp@keithp.com>
This causes a failure when evaluating $OSTYPE on systems which do not
set that variable (everything but Msys/MinGW)
Signed-off-by: Keith Packard <keithp@keithp.com>
Akira TAGOH
Jon Turney
Keith Packard
Behdad Esfahbod