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>
This saves the value of FONTCONFIG_SYSROOT in the config instead of
having to call getenv every time we need this value.
This also uses 'realpath' to construct a canonical path to sysroot,
eliminating symlinks and relative path names.
Signed-off-by: Keith Packard <keithp@keithp.com>
The generic family of 'system-ui' name is being proposed in a draft of next CSS Fonts.
This would be nice to support in fontconfig too.
https://www.w3.org/TR/css-fonts-4/
All non trivial users of FontConfig must use FcConfigGetSysRoot to
resolve file properties in patterns. In order to support sysroot the
filename in the file property must be relative to the sysroot, but the
value of the file property in a pattern is directly exposed, making it
impossible for FontConfig to resolve the filename itself transparently.
Otherwise, there would be build errors in the following 2 cases:
* define HAVE_POSIX_FADVISE
Or:
* undef HAVE_POSIX_FADVISE
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
This fixes the sort of weird things like `fc-match :size=rgb` done without any errors.
This might be annoyed but the error messages should helps to fix an application bug or
suggest more useful constant names to fontconfig.
Fixes https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/137
"color" property has a value more than 1 because the value of FT_HAS_COLOR
is directly set to it. this seems breaking the behavior of FcFontList with FC_COLOR=true
because it is more than FcDontCare.
So changing comparison that way.
Because FcDirCacheDeleteUUID does not reset the modification time on
the directory, and because FcDirCacheRead unconditionally creates the
UUID file each time it is run, any empty directory in the cache will
get its timestamp changed each time the cache for that directory is
read.
Instead, just leave the UUID file around as it is harmless.
The alternative would be to only create the UUID file after the cache
has been created and the directory has been discovered to be
non-empty, but that would delay the creation of the UUID file.
Signed-off-by: Keith Packard <keithp@keithp.com>
Keith Packard
Akira TAGOH
Ben Wagner
Robert Yang
Chris McDonald
Behdad Esfahbod